[qubes-users] Announcing our 2019 Season of Docs project: Onboard with Qubes OS!
-BEGIN PGP SIGNED MESSAGE- Hash: SHA512 Dear Qubes Community, The Season of Docs program has announced [1] the technical writing projects chosen for 2019. We are pleased to congratulate Lukas à Porta (aka luzeal) [2] on the selection of his project: "Onboard with Qubes OS!" [3] We received many excellent proposals from talented writers. Unfortunately, we had to choose just a single one, and this decision was extremely difficult. Regardless of whether you applied or your proposal was accepted, we invite you to collaborate on the Qubes documentation. [4] The documentation is primarily a community effort, and it only gets better when you get involved! [1] https://opensource.googleblog.com/2019/08/season-of-docs-announces-technical.html [2] https://groups.google.com/d/topic/qubes-project/0AdqOTpuW1Q/discussion [3] https://developers.google.com/season-of-docs/docs/participants/project-qubes [4] https://www.qubes-os.org/doc/doc-guidelines/ This announcement is also available on the Qubes website: https://www.qubes-os.org/news/2019/08/07/announcing-our-2019-season-of-docs-project/ - -- Andrew David Wong (Axon) Community Manager, Qubes OS https://www.qubes-os.org -BEGIN PGP SIGNATURE- iQIzBAEBCgAdFiEEZQ7rCYX0j3henGH1203TvDlQMDAFAl1LtCYACgkQ203TvDlQ MDDNThAAi3v/TvT/usKmNmGbnvoWtTYafywn12zny6ev2CEAwC9pTJgl832OUOa4 C57250FfcMVleFsebEbSTsmW1/TZSt57No4Kqk0CrmDeFUbOw4fPFLhOc07508LO GC9+7+AKLYbmoKf5jlx18a/x5e32hI5nU+TSjFPqhBXv1NeL+eEeSyeqYHrFJtzo DmTqWsaIte0oJ/aSiN1e/bTZIDMg1hSBGxwZcWGzUQ/RnpTa21K2SgggZ4WLQL8Q cV5oUsPYIvO7CYrDWXnxhtZo87e5o7sF+7KJuYFJ4es9nAPWCTHnaKmaqvo98XIb Z1xsG4PxYcqUT4VMHvgTyQ6bb9GBX9ndfjfn/A9sDN7FwHQNQjBaG9ccy7l27g4g C4NGllF0y9Td2z1GVOuj5J06VELU3L5lH1GtLPkiCa6+GYGV3iMFPhIR/IFjZqZH yMY71anE1K75CpyxmwXZ0v+i2G/qRTOu1MDukVVRgyAoU+upTqwhIml0ri4LfNVW 8KMNG9CnZ3q6DtkGOja02/eWhMi8FbKL1sJ9KpFOzfD/k/eoq25ZnBMixBIMn0Tr tdGwxx7dYRGFHwDaj7HFR1Hlcrip99vgw2Aygj0wioxA2JAAiUHQjWklId1BIy3n /bEzP8IuJ0PZS0hxyyqOaqTtmnrF1Mp4sLvvPurC7F9VYccEsuQ= =lSww -END PGP SIGNATURE- -- 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/9c04672a-6aea-da89-e538-0b118845f25e%40qubes-os.org.
Re: [qubes-users] Caching update packages for templates
-BEGIN PGP SIGNED MESSAGE- Hash: SHA512 On 07/08/2019 7.55 PM, drogo wrote: > Is there an easy way to enable caching for template update > packages? It's annoying to have to download hundred of megs over > and over while updating templates. I see there's already a proxy > configured and listening on port 8082, so can I just enable caching > of those packages somewhere in Qubes' networking stream to speed up > those downloads? > > Thanks. > Please have a look at this issue: https://github.com/QubesOS/qubes-issues/issues/1957 - -- Andrew David Wong (Axon) Community Manager, Qubes OS https://www.qubes-os.org -BEGIN PGP SIGNATURE- iQIzBAEBCgAdFiEEZQ7rCYX0j3henGH1203TvDlQMDAFAl1LmRoACgkQ203TvDlQ MDCefw//a3nMQJIGYgtRPLsEV4jCqMyiUDiAZsiF4LWBy6qUqKWB2TSnzLK3IHOx jFfcG7sTgQfi6teJiH9wvLralkOHA3pMT/PlJKBDUASOzjnqEE2mirUgGTR8DgCt EROTcQ1hCYswH7M3FiQ2lR3Hv3Br6W1elt/bbOl55U3sTQ3dvVFcMrZP+c1iW5Si xOJW9r3Ndu058sQkCl4RkLG/b3BnyFTEkbhcYqUA9MgJJFdjImA+g0VgYy7Cg1xD VU+7xoFmtFB50RaAKFjX1wdfj1oaH0IHQHt1SyImtR7oUR+S6WaEnxcuvZS6iz5R 8wEjFuYnVcZ+IScyG4iQqoJdYyfnYA61oh0hu/SBQMEfcm5uqJv1NzEOwK2T8WAH 9HHO89q3HftI2B8ycI/Qq1QaZBilLI5fcQi5VbcKLx/iTcD5AlF6tx6eHJpcUycT fSwhc7MQU8t0B4xya6TiyiC4k3Q1VQlBZDtOL03ABYokFWcAofFPE7EMDrgHxrge 3ynCMIUywRVIMoq4xSY5LF4ZQIJek/yE2quUeVJ+MMyzpd03U58kHkbHTXLEDVgg TGqS1cRZ5dWYiewAesd1JvuLwtX34wl1SaNEvpd8EE0C/1/kmX6iPs9BK5MprdsI bhTqOCY7ZfUB+KLOcBMz2Aojt8TfWhDSrBg9gmzS2xGmMiDMhWI= =U1wT -END PGP SIGNATURE- -- 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/943054ff-15cd-a7a7-f2d5-7bb2e9d06029%40qubes-os.org.
[qubes-users] Caching update packages for templates
Is there an easy way to enable caching for template update packages? It's annoying to have to download hundred of megs over and over while updating templates. I see there's already a proxy configured and listening on port 8082, so can I just enable caching of those packages somewhere in Qubes' networking stream to speed up those downloads? Thanks. -- 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/1309e16c-45ed-4660-aefe-3e2216ecb562%40googlegroups.com.
Re: [qubes-users] handling DNS resolution when running comercial VPNs
On 8/7/19 11:23 AM, thecodingninjaisb...@gmail.com wrote: On Wednesday, August 7, 2019 at 9:45:51 AM UTC-4, Chris Laprise wrote: On 8/7/19 9:39 AM, thecodingn...@gmail.com wrote: > > > On Tuesday, August 6, 2019 at 9:45:51 PM UTC-4, Chris Laprise wrote: > > On 8/6/19 7:57 PM, thecodingn...@gmail.com wrote: > > Running ```sudo iptables -C FORWARD -o eth0 -j DROP``` throws an > error > > itself: iptables: Bad rule (does matching rule exist in that > chain?). So > > how can this ever run if running it directly in bash from inside the > > appvm does not work? > > > > On Tuesday, August 6, 2019 at 7:47:53 PM UTC-4, > thecodingn...@gmail.com > > wrote: > > > > So apparently the tasket repo does not work|out of the box > > (obviously). Working through everything, now ran into an > unfamiliar > > issue: pre-start firewall check fails with status 1. Looking > at the > > code it seems the firewall rules are not there although firewall > > service is running actively. Executing the for loop in a > standalone > > bash throws:| > > | > > | > > Fatal:can't open lock file /run/xtables.lock: Permission denied > > | > > The file is there, but i'm thinking this denial is purposeful > and i > > prob should not sudo the loop execution. Any advice? > > FYI, the qubes lists discourage top-posting. Please reply at the > bottom. > > The firewall rules should be in > /rw/config/qubes-firewall.d/90_tunnel-restrict. If they're not, this > may > indicate the setup steps were not followed through to completion (i.e. > if you installed to your template, but forgot step 4). > > -- > > Chris Laprise, tas...@posteo.net > https://github.com/tasket > https://twitter.com/ttaskett > PGP: BEE2 20C5 356E 764A 73EB 4AB3 1DC4 D106 F07F 1886 > > > you are right, but following exact instructions does not work as the > following condition fails: > ConditionPathExistsGlob=/var/run/qubes-service/vpn-handler* was not met > > There's not such service to be found under /var/run/qubes-service and in > qube settings dialog, there's no such service to add to the vm. Per step 1... "add vpn-handler-openvpn to the ProxyVM's Settings / Services tab by typing it into the top line and clicking the plus icon." You have to type it in first and click 'plus' icon. -- Chris Laprise, tas...@posteo.net https://github.com/tasket https://twitter.com/ttaskett PGP: BEE2 20C5 356E 764A 73EB 4AB3 1DC4 D106 F07F 1886 The proxy-firewall-restrict seems to get lost after each restart causing the --check-firewall to fail. I tried calling this script from rc.local directly and even tried adding it to the qubes-firewall-user-script, but neither solved the issue. I'd have to manually open terminal in vm and call the restrict using sudo, then restart the qubes-vpn-handler service using systemctl. Any solutions to this? This sounds like you ran 'install' in two different places, both the template and the proxy vm; It should be only one. If that's the case, you can try disabling the rc.local script. Also, which Qubes template are you using? -- Chris Laprise, tas...@posteo.net https://github.com/tasket https://twitter.com/ttaskett PGP: BEE2 20C5 356E 764A 73EB 4AB3 1DC4 D106 F07F 1886 -- 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/f4da9c5a-f214-a5f2-9774-6cb6c12391c6%40posteo.net.
Re: [qubes-users] handling DNS resolution when running comercial VPNs
On Wednesday, August 7, 2019 at 9:45:51 AM UTC-4, Chris Laprise wrote: > > On 8/7/19 9:39 AM, thecodingn...@gmail.com wrote: > > > > > > On Tuesday, August 6, 2019 at 9:45:51 PM UTC-4, Chris Laprise wrote: > > > > On 8/6/19 7:57 PM, thecodingn...@gmail.com wrote: > > > Running ```sudo iptables -C FORWARD -o eth0 -j DROP``` throws an > > error > > > itself: iptables: Bad rule (does matching rule exist in that > > chain?). So > > > how can this ever run if running it directly in bash from inside > the > > > appvm does not work? > > > > > > On Tuesday, August 6, 2019 at 7:47:53 PM UTC-4, > > thecodingn...@gmail.com > > > wrote: > > > > > > So apparently the tasket repo does not work|out of the box > > > (obviously). Working through everything, now ran into an > > unfamiliar > > > issue: pre-start firewall check fails with status 1. Looking > > at the > > > code it seems the firewall rules are not there although > firewall > > > service is running actively. Executing the for loop in a > > standalone > > > bash throws:| > > > | > > > | > > > Fatal:can't open lock file /run/xtables.lock: Permission > denied > > > | > > > The file is there, but i'm thinking this denial is purposeful > > and i > > > prob should not sudo the loop execution. Any advice? > > > > FYI, the qubes lists discourage top-posting. Please reply at the > > bottom. > > > > The firewall rules should be in > > /rw/config/qubes-firewall.d/90_tunnel-restrict. If they're not, this > > may > > indicate the setup steps were not followed through to completion > (i.e. > > if you installed to your template, but forgot step 4). > > > > -- > > > > Chris Laprise, tas...@posteo.net > > https://github.com/tasket > > https://twitter.com/ttaskett > > PGP: BEE2 20C5 356E 764A 73EB 4AB3 1DC4 D106 F07F 1886 > > > > > > you are right, but following exact instructions does not work as the > > following condition fails: > > ConditionPathExistsGlob=/var/run/qubes-service/vpn-handler* was not met > > > > There's not such service to be found under /var/run/qubes-service and in > > qube settings dialog, there's no such service to add to the vm. > > Per step 1... "add vpn-handler-openvpn to the ProxyVM's Settings / > Services tab by typing it into the top line and clicking the plus icon." > > You have to type it in first and click 'plus' icon. > > -- > > Chris Laprise, tas...@posteo.net > https://github.com/tasket > https://twitter.com/ttaskett > PGP: BEE2 20C5 356E 764A 73EB 4AB3 1DC4 D106 F07F 1886 > The proxy-firewall-restrict seems to get lost after each restart causing the --check-firewall to fail. I tried calling this script from rc.local directly and even tried adding it to the qubes-firewall-user-script, but neither solved the issue. I'd have to manually open terminal in vm and call the restrict using sudo, then restart the qubes-vpn-handler service using systemctl. Any solutions to this? -- 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/9f6fc37e-be5b-4335-9102-04ab182164b1%40googlegroups.com.
Re: [qubes-users] Receive-only email VM
On 8/2/19 1:24 PM, reddit@vfemail.net wrote: In Qubes, is it possible to set up a VM that can receive email, but not send information out, via email or otherwise? The motivation is: Many online accounts rely on an email address to reset passwords. However, the VM that handles inbound emails, processes a lot of untrusted input. If the VM gets compromised by an attacker, the attacker can then send password reset emails and read them. So to defend against this, I want to prevent the compromised VM from communicating out the contents of these password reset emails. Specifically: 1. Assume the VM is compromised (can't rely on in-VM enforcement mechanisms). 2. Assume the email provider is not compromised To further illustrate the problem, here are example setups and why they don't work: Setup 1: Use qubes firewall to restrict to the email provider's server and IMAP port. Block UDP requests using qvm-firewall. Why it doesn't work: Attacker can create an account on the same email provider and connect to their account (the firewall rules will not prevent this). They can then sync emails containing any data, to their account. Setup 2: Like Setup 1, but use POP3. Why it doesn't work: Attacker creates account at provider, transmits data via POP3 delete operations. How about setup the firewall to black hole the entire IP range of the email service company, then set up a proxy on the firewall which you then control, and you set their email program to use the proxy. If need be you can black hole all the pop/smtp/imap ports for all Internet traffic forcing them to use the proxy for any email no matter what email program or provider they use. When they try to send any email the proxy simply closes that connection. Controlling HTTP/s traffic might be more difficult, but if necessary you can proxy all that as well. If its just one service provider you care about then the black hole IP trick should do the job. You put any custom logic for your specific requirements into the proxy which then controls their access accordingly. Basically its a default deny gateway which needs to match on the permitted rules before they are ever granted access. The downside is you will likely need to write your own proxy for this. -- 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/bd97b81b-5b13-ff22-42b5-21505054e34c%40jhuapl.edu.
Re: [qubes-users] handling DNS resolution when running comercial VPNs
On 8/7/19 9:39 AM, thecodingninjaisb...@gmail.com wrote: On Tuesday, August 6, 2019 at 9:45:51 PM UTC-4, Chris Laprise wrote: On 8/6/19 7:57 PM, thecodingn...@gmail.com wrote: > Running ```sudo iptables -C FORWARD -o eth0 -j DROP``` throws an error > itself: iptables: Bad rule (does matching rule exist in that chain?). So > how can this ever run if running it directly in bash from inside the > appvm does not work? > > On Tuesday, August 6, 2019 at 7:47:53 PM UTC-4, thecodingn...@gmail.com > wrote: > > So apparently the tasket repo does not work|out of the box > (obviously). Working through everything, now ran into an unfamiliar > issue: pre-start firewall check fails with status 1. Looking at the > code it seems the firewall rules are not there although firewall > service is running actively. Executing the for loop in a standalone > bash throws:| > | > | > Fatal:can't open lock file /run/xtables.lock: Permission denied > | > The file is there, but i'm thinking this denial is purposeful and i > prob should not sudo the loop execution. Any advice? FYI, the qubes lists discourage top-posting. Please reply at the bottom. The firewall rules should be in /rw/config/qubes-firewall.d/90_tunnel-restrict. If they're not, this may indicate the setup steps were not followed through to completion (i.e. if you installed to your template, but forgot step 4). -- Chris Laprise, tas...@posteo.net https://github.com/tasket https://twitter.com/ttaskett PGP: BEE2 20C5 356E 764A 73EB 4AB3 1DC4 D106 F07F 1886 you are right, but following exact instructions does not work as the following condition fails: ConditionPathExistsGlob=/var/run/qubes-service/vpn-handler* was not met There's not such service to be found under /var/run/qubes-service and in qube settings dialog, there's no such service to add to the vm. Per step 1... "add vpn-handler-openvpn to the ProxyVM's Settings / Services tab by typing it into the top line and clicking the plus icon." You have to type it in first and click 'plus' icon. -- Chris Laprise, tas...@posteo.net https://github.com/tasket https://twitter.com/ttaskett PGP: BEE2 20C5 356E 764A 73EB 4AB3 1DC4 D106 F07F 1886 -- 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/8ff851ed-f439-0f4a-b618-e9c3242e1eed%40posteo.net.
Re: [qubes-users] handling DNS resolution when running comercial VPNs
On Tuesday, August 6, 2019 at 9:45:51 PM UTC-4, Chris Laprise wrote: > > On 8/6/19 7:57 PM, thecodingn...@gmail.com wrote: > > Running ```sudo iptables -C FORWARD -o eth0 -j DROP``` throws an error > > itself: iptables: Bad rule (does matching rule exist in that chain?). So > > how can this ever run if running it directly in bash from inside the > > appvm does not work? > > > > On Tuesday, August 6, 2019 at 7:47:53 PM UTC-4, thecodingn...@gmail.com > > wrote: > > > > So apparently the tasket repo does not work|out of the box > > (obviously). Working through everything, now ran into an unfamiliar > > issue: pre-start firewall check fails with status 1. Looking at the > > code it seems the firewall rules are not there although firewall > > service is running actively. Executing the for loop in a standalone > > bash throws:| > > | > > | > > Fatal:can't open lock file /run/xtables.lock: Permission denied > > | > > The file is there, but i'm thinking this denial is purposeful and i > > prob should not sudo the loop execution. Any advice? > > FYI, the qubes lists discourage top-posting. Please reply at the bottom. > > The firewall rules should be in > /rw/config/qubes-firewall.d/90_tunnel-restrict. If they're not, this may > indicate the setup steps were not followed through to completion (i.e. > if you installed to your template, but forgot step 4). > > -- > > Chris Laprise, tas...@posteo.net > https://github.com/tasket > https://twitter.com/ttaskett > PGP: BEE2 20C5 356E 764A 73EB 4AB3 1DC4 D106 F07F 1886 > you are right, but following exact instructions does not work as the following condition fails: ConditionPathExistsGlob=/var/run/qubes-service/vpn-handler* was not met There's not such service to be found under /var/run/qubes-service and in qube settings dialog, there's no such service to add to the vm. -- 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/5bfc5a57-9aaf-4018-944d-e3507fc340f7%40googlegroups.com.
[qubes-users] randomly lost of network connection after reboot
Hello, I use one ipc3 (compulab) with qubes-os4, fedora29, no NetworkManager. I have a bad behavior, after reboot, randomly, i can't ping others computer with rj45 ethernet (no wifi using) No issues with fedora configuration as iptable, route and... I reboot several times and the connection can raise up without conf modification. I never lose the ethernet connection until one reboot. No error message in logs about e1000e / igb intel module, pci or other think linked to ethernet use. Somebody would have one idea of this issue? Thanks. Alain -- 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/c52ec072-b98e-4107-8ac1-e2a9007c08eb%40googlegroups.com.
[qubes-users] Error when updating Dom0 "error: could not delete old database at /var/lib/qubes/dom0-updates/home/user/.rpmdbold.2380"
When updating dom0 (sudo qubes-dom0-update) I keep getting: error: could not delete old database at /var/lib/qubes/dom0-updates/home/user/.rpmdbold.2380 It doesn't seem like this is causing an issue but I would like to delete the old database. I think I found a solution but I wanted to make sure its sound before i try it. Feedback would be appreciated. > https://unix.stackexchange.com/questions/395468/yum-and-rpm-error-rpmdbnextiterator-skipping-h#464986 > > $ sudo rpmdb --rebuilddb -v > error: could not delete old database at /var/lib/rpmold.17138 > > $ sudo rm -rf /var/lib/rpmold.17138 > > $ sudo rpmdb --rebuilddb -v > > $ sudo dnf update --refresh > determining the fastest mirror (2 hosts).. done. > RPM Fusion for Fedora 28 - Free - Updates > > 412 kB/s | 369 kB 00:00 > RPM Fusion for Fedora 28 - Nonfree - Updates > > 35 kB/s | 84 kB 00:02 > Last metadata expiration check: 0:00:00 ago on Mon 27 Aug 2018 09:08:56 AM > +08. > Dependencies resolved. > Nothing to do. > Complete! Thanks in advance Xaver Sent with [ProtonMail](https://protonmail.com) Secure Email. -- 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/U8AIz7-OciUY4VZ8N0CVxsof0WhVg2gCvtAVa-V2u-96-v1T4CpepjVPqaZkSSXQY3d-6cHnNgm1RzmfzDNU5e9cCfMqBn2KwREonBnFdBg%3D%40protonmail.com.
