Re: [qubes-devel] Wrong formula in gui-configuration doc?
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 On Tue, Apr 23, 2024 at 11:47:42AM -, qubist wrote: > I see this (essential lines only): > > # Only primary (4K) screen connected: > > user@dom0:~ > xrandr > DP-1 connected primary 3840x2160+0+0 (normal left inverted right x axis y > axis) 596mm x 335mm >3840x2160 60.00*+ 29.9824.9924.00 > > # Only secondary (2K) screen connected w/ scale 2x2: > # (note: No idea why the weird dimensions in mm, it's a big screen) > > DP-2 connected 3840x2160+0+0 (normal left inverted right x axis y axis) 16mm > x 9mm >1920x1080 60.00* 50.0059.9424.0023.98 > > # Both, side by side, 4K primary, 2K secondary w/ scale 2x2: > > DP-1 connected primary 3840x2160+0+0 (normal left inverted right x axis y > axis) 596mm x 335mm >3840x2160 60.00*+ 29.9824.9924.00 >... > DP-2 connected 3840x2160+3840+1080 (normal left inverted right x axis y axis) > 16mm x 9mm >1920x1080 60.00* 50.0059.9424.0023.98 > > > What is the formula? (3840 + 3840) * 2160 * 4 / 1024 And even easier, you should have a top line in xrandr output with "current ... x ..." - that's the total size you are after. > P.S. > > FWIW, the secondary (2K) screen is connected via HDMI, however xrandr > always shows HDMI-1 and HDMI-2 as disconnected and "thinks" the > secondary screen is on DP-2 (while there is only one physical > DisplayPort). No idea if this is a bug or even related in any way. It's probably related how those connectors are routed, maybe there is some internal converter. But could be also mislabeled outputs in the driver. - -- Best Regards, Marek Marczykowski-Górecki Invisible Things Lab -BEGIN PGP SIGNATURE- iQEzBAEBCAAdFiEEhrpukzGPukRmQqkK24/THMrX1ywFAmYnqGkACgkQ24/THMrX 1ywg1gf9HJQJnkXOOXV/a7ttUlwm5lINhwZ7KSAqOqCX8rklWZqeVtal4ywDeld6 1G9jpL7u+yq3qZZgPYJPOoEK5VNfI5VTDFICN9xrelwJDZsZvLlrWc9qU4ddB+FW yEYcCoEGsK9GGYrieFhBQaVOtmSlcvyWVnfhLaHdiL8JfL0GTx8DiF7ZxJbDM28h 7VAdPJPsivunchjKdww+d5gvpFEv3ISxOR790EL8nOCmIypBpJ7cEvmz7/qF9DY1 iyggJ340yYHVyeRu9aHG2/KfHT04GFcHqN2YQBj/f3xj9H07Qm77DVD4mM59d7h9 ktWLlI0YQmGgNMXPeEk7Wa416g6o+w== =Icq+ -END PGP SIGNATURE- -- You received this message because you are subscribed to the Google Groups "qubes-devel" group. To unsubscribe from this group and stop receiving emails from it, send an email to qubes-devel+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/qubes-devel/ZieoaZRUcoEiKoz_%40mail-itl.
Re: [qubes-devel] Firewall antispoofing in ingress hook
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 On Tue, Apr 23, 2024 at 11:57:14AM -, qubist wrote: > On Tue, 23 Apr 2024 13:42:25 +0200 Marek Marczykowski-Górecki wrote: > > > xendriverdomain daemon (xl devd), when the vif interface is > > created/removed. > > Thanks. > > > I'd use some packet generator, maybe even ping (or nping) will be > > enough. You can easily try spoofing by changing IP inside some test > > VM. > > Well, I have been using hping3 for spoofing but it doesn't provide a > measure. I thought that by measure you mean something along the lines > of network throughput during a heavy spoofing load. I'd simply generate some traffic and observe CPU load in the firewall vm. - -- Best Regards, Marek Marczykowski-Górecki Invisible Things Lab -BEGIN PGP SIGNATURE- iQEzBAEBCAAdFiEEhrpukzGPukRmQqkK24/THMrX1ywFAmYnpzAACgkQ24/THMrX 1yz1BAf/TUImu5wA+HKsonG0hRnTZCxBQ57/oZn2H/8fX8k6B84a9USBaZghygvD G41usqvZM/9mBUCMNk1o0ayCIseYOwsvp2bPOLX9WmSNMamL+rPCKcFTTQ6Jmwnv XPGV//UQ9EwwWYuSf4ApeTO3NgeNI/NThhLyq99WUxz+CkNqBuPI4TZ9VtEmhAZy KkVNT/PDCIpv09l8gjm8NIwkSAzsbT1wZTYZgd2ygIwZdz+ClsqPwlpZZ8R41YGy YYiqgSxXAHE89foMzAYvq4UmaOrCReJBChJpwyPwxVLeBBqqyYD0pMe14Gmw7LJA DE4VhNZA9sBmwHPvD9uvAahyqodWXA== =9g30 -END PGP SIGNATURE- -- You received this message because you are subscribed to the Google Groups "qubes-devel" group. To unsubscribe from this group and stop receiving emails from it, send an email to qubes-devel+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/qubes-devel/ZienMCTD80N6ftZV%40mail-itl.
Re: [qubes-devel] What ensures the lack of VM IP address duplicates?
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 On Tue, Apr 23, 2024 at 11:22:06AM -, qubist wrote: > On Tue, 23 Apr 2024 12:20:57 +0200 Marek Marczykowski-Górecki wrote: > > > You mean using something else than vif-route-qubes network script (or > > some other way to reconfigure vif interfaces)? > > I don't know if I mean that as I have not studied that script > thoroughly. What I mean is in the general sense: the assumption that > MAC addresses should be unique within a LAN. I don't know how that is > related to bridge/no-bridge. Ok, so the answer is in my previous email - on the setup we use, each VM has its own subnet. - -- Best Regards, Marek Marczykowski-Górecki Invisible Things Lab -BEGIN PGP SIGNATURE- iQEzBAEBCAAdFiEEhrpukzGPukRmQqkK24/THMrX1ywFAmYnnywACgkQ24/THMrX 1yzpQwf5AdjX3W7HnDGP8KUv4cUHRh1Wt6yjFLLS0gl23LYof1G2CNLl/cW5yD8z bexAA4QfRCqXlslG8CJrMr9WuIY3cqjTHdtF3kUFrhA3DgSTHgD+nk9eijVRyvTL yTKfWXgfjmTQfz8DgbF4GtdZ2QNIDwgu3fN0O34YXwpnQBROmZzPk/E/ByciMenz rZhgSYaCGcJYQjImorKWqVHMS4no5xHnT1KpyOMMzFgYIn3jmIo8XBrX+E7KPrg5 4C3vVEE629s1FVLKJoCnHgCDDLJhgz27HravlS63ExEsVHdqo4UHgNcJIM7wgOtK GClKQo4Qr2et6bjt2CBqc6WDB1yWrg== =q2ME -END PGP SIGNATURE- -- You received this message because you are subscribed to the Google Groups "qubes-devel" group. To unsubscribe from this group and stop receiving emails from it, send an email to qubes-devel+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/qubes-devel/ZiefLOgyjYBpv1XR%40mail-itl.
Re: [qubes-devel] Firewall antispoofing in ingress hook
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 On Tue, Apr 23, 2024 at 11:16:56AM -, qubist wrote: > On Tue, 23 Apr 2024 12:04:22 +0200 Marek Marczykowski-Górecki wrote: > > > Care to open a pull request then? > > A few things: > > 1. The customizations I am working on are atomic nftables tables, > chains and rules. So far, they work fine independently and along with > the current default firewall. > > 2. I still don't know how to work with git efficiently, so this "pull > request" is something I need to learn about first. All I know so far is > how to create a project and commit changes. > > 3. My firewall work (which involves other improvements, I hope) is > still not complete. As soon as it is, I would gladly share it. > > > This is done in the vif hotplug script: > > https://github.com/QubesOS/qubes-core-agent-linux/blob/main/network/vif-route-qubes#L222-L223 > > Thanks! Bash is fine for me, so I will see what modification works > best. What calls that script BTW? xendriverdomain daemon (xl devd), when the vif interface is created/removed. > > Have you measured it? > > Not yet. At least not in a way deserving to be called measurement. All > I have done is to trace the result and see that ingress works with less > steps. If you know a good way to measure it correctly, please let me > know. I'd use some packet generator, maybe even ping (or nping) will be enough. You can easily try spoofing by changing IP inside some test VM. > > I'd say it's up to ones who propose a change to justify it. > > Of course. > > > Or do you mean moving just "antispoof" chain out of "prerouting" and > > have it hooked directly? > > I am testing my stuff in the netdev with priority -500. However, > ingress is available in prerouting too, so that move might work as well. - -- Best Regards, Marek Marczykowski-Górecki Invisible Things Lab -BEGIN PGP SIGNATURE- iQEzBAEBCAAdFiEEhrpukzGPukRmQqkK24/THMrX1ywFAmYnnqEACgkQ24/THMrX 1ywroAf/U0Iq2WsIFs1HPv/PGobjCdEz5cSFsL+4fWACYydi+Cqtj8EOQmc1cRh/ ei9xYpGcQYFD69/suZZuostkb87LIuwNsA/jJ2NDQjnCdM1G/i0Z/lUoPAuNNb07 h3csaDGQPWtKuLAM30ADsVSa+dneAyu9tkK+xAOI+Kq8R+UjkVPr1Dxdnf5RXHSL niFIicJB6U9+cVCO8jr/3O4DgYp8xf1GsL6uCXx9bPgO25R57Y+Mcga5Jam1SeG7 P5f3REk91kiZ2BZG5kmlfg9ipAE/Fyx9y4QLcz9fcafzwu17NFZlP+jRDShqLKAx ijh44R63lS1nT5TiPJFYLbsrMmtQEg== =xJVU -END PGP SIGNATURE- -- You received this message because you are subscribed to the Google Groups "qubes-devel" group. To unsubscribe from this group and stop receiving emails from it, send an email to qubes-devel+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/qubes-devel/ZieeocPY_0fxKw5M%40mail-itl.
Re: [qubes-devel] Wrong formula in gui-configuration doc?
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 On Tue, Apr 23, 2024 at 05:33:14AM -, qubist wrote: > On Mon, 22 Apr 2024 21:24:36 +0200 Marek Marczykowski-Górecki wrote: > > > It's about the pixel count as seen by the applications, which may not > > necessarily be the display resolution if scaling is involved. > > Are you saying that scaling means preserving the original pixel count > (i.e. apps draw on the original, unscaled canvas) and then the whole > thing is scaled down in real time? Is this how xrandr works? Let me clarify it this way: when using scaling, you will see for example eDP-1 connected primary 1920x1080+0+1200 (normal left inverted right x axis y axis) 309mm x 174mm 2560x1440 60.00*+ 59.9959.9959.9659.95 ... Use the 1920x1080 in the formula, not 2560x1440 - -- Best Regards, Marek Marczykowski-Górecki Invisible Things Lab -BEGIN PGP SIGNATURE- iQEzBAEBCAAdFiEEhrpukzGPukRmQqkK24/THMrX1ywFAmYnjHMACgkQ24/THMrX 1yy6PwgAiyBrVYEnreVgRyBq6/NNQUZR8rd3b5rjzixDdZMRrNfPZ7F1rX+ww+jn c3iROIcepGTzPogM7bBQJpco+Qa5jEcp5mfyN6z62D8IBvP6hZZNwcVY80o3lCzZ DhvVuvz49bA00CW98gppo9SjNT9v15YKW+NVVim7qtPsMTAglz1tNx9hbnsCtB9m oP2k816/AAbSvdaqAbcYqjP/T8Vcety+k3zH5bZ2ZAooQTXulZ49b74inl9nUFWJ KzKtPY7zkw+cyYwwYIVEpNSMkEePMhHUHaeQHgN7wsMHuP91SD2SB4DthvujIuqq BB9gOHSF8K5Vt2RJtjiDsG5EMW6hAQ== =Foc3 -END PGP SIGNATURE- -- You received this message because you are subscribed to the Google Groups "qubes-devel" group. To unsubscribe from this group and stop receiving emails from it, send an email to qubes-devel+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/qubes-devel/ZieMc8Qbi8JosCNr%40mail-itl.
Re: [qubes-devel] What ensures the lack of VM IP address duplicates?
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 On Tue, Apr 23, 2024 at 10:15:56AM -, qubist wrote: > On Tue, 23 Apr 2024 12:07:12 +0200 Marek Marczykowski-Górecki wrote: > > > Yes, the key part is "on the same subnet". Each VM-VM link is > > effectively a separate "subnet" with just two endpoints (eth0 > > interface in one VM and vif interface in the other). We do not use > > bridges. > > I see. What about the case of a custom virtual LAN, involving multiple > VMs (still routed by sys-firewall)? Wouldn't same MACs create a problem? You mean using something else than vif-route-qubes network script (or some other way to reconfigure vif interfaces)? I don't think we allow to choose network script, and that's the place (libvirt config) where mac address is set too. So, if you change one, you can very well change the other too. > > If you like, you can set any mac address using qvm-prefs, and here you > > don't need to worry about its uniqueness :) > > Is this what one must do for the case described above? I guess so. But we don't really support bridged configuration. - -- Best Regards, Marek Marczykowski-Górecki Invisible Things Lab -BEGIN PGP SIGNATURE- iQEzBAEBCAAdFiEEhrpukzGPukRmQqkK24/THMrX1ywFAmYni4kACgkQ24/THMrX 1yw9Sgf+NOHAGPeFQsau37qM4QOerQKJUHzUxrxVAtGKUonXIrGVkGCU5EnQEAbb iSMsObPO90kR5l+vNKCZt+xOAsMp9KWUSZ/EnwIwklSo5VNRPw0s4PexFD+etosH gW9UMopmhfder4XwQ6IPnK4mSITpuMGZDecOJJ2xLnGaQHaOBOQJ5FihWQxN3bEQ 9oXVGEwMvy1EhbuWBJR9/XFRqhys1jSsVKaI5agseiMnZbjO39XMpSy83V2FXI0L UmFg4uWwaQJ+Z1DqFJDPz5QvBWNbx4pteMZJh2NhNUVbA+VuxdnNUsPs/w8/vFiE abqln1OBrTP5zJVKTb2S22imt/EC8A== =G/a6 -END PGP SIGNATURE- -- You received this message because you are subscribed to the Google Groups "qubes-devel" group. To unsubscribe from this group and stop receiving emails from it, send an email to qubes-devel+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/qubes-devel/ZieLiQs-4WClOsk_%40mail-itl.
Re: [qubes-devel] What ensures the lack of VM IP address duplicates?
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 On Tue, Apr 23, 2024 at 08:45:36AM -, qubist wrote: > Thanks. > > What about MAC addresses? Why do all VMs use the same one? > Aren't MAC addresses required to be unique on the same subnet? Yes, the key part is "on the same subnet". Each VM-VM link is effectively a separate "subnet" with just two endpoints (eth0 interface in one VM and vif interface in the other). We do not use bridges. If you like, you can set any mac address using qvm-prefs, and here you don't need to worry about its uniqueness :) - -- Best Regards, Marek Marczykowski-Górecki Invisible Things Lab -BEGIN PGP SIGNATURE- iQEzBAEBCAAdFiEEhrpukzGPukRmQqkK24/THMrX1ywFAmYniFAACgkQ24/THMrX 1ywSuwgAk2YpFfGWkH7umkloeLwBuBo+IlNu5AxjP7gji2WSQZpZKLW4hDJAKO/K +c/5zbvh/TORyT2/4KB/RxpilvpRsgGLPdFf8f36coUGywDu8Gk3EXtAG+r6hPyY ryVXD3UEj54F5+MEYmlRU1GfGLOFJ9u/WG7tDDnPDs4EmIgLzJWbQUswnXTfWmyP fHuT3gJW9+AcJ1ADYpupbT271YYv2mbNBL3mWOt0d9F2cBSWPbDKTin92O9/EzLi cd2T0OCoUhPcF8F8P5ZT/rzuCe2K+Y1ovoGSsy4Wr2wjaZVxEF4ZuuSaKLtFQKUm nnKZa2vOzaOBMPKW6F45XjC0MxaNcg== =mTeN -END PGP SIGNATURE- -- You received this message because you are subscribed to the Google Groups "qubes-devel" group. To unsubscribe from this group and stop receiving emails from it, send an email to qubes-devel+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/qubes-devel/ZieIUMYXja6mPPVk%40mail-itl.
Re: [qubes-devel] Firewall antispoofing in ingress hook
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 On Tue, Apr 23, 2024 at 08:40:04AM -, qubist wrote: > On Mon, 22 Apr 2024 22:41:40 +0200 Marek Marczykowski-Górecki wrote: > > > The "antispoof" chain is hooked via the "raw" priority, which happens > > before all kind of connection tracking, routing etc, basically as > > early as firewall can see whole IP packets (not for example only their > > fragments). > > I can see how it is done but why would one need to (potentially) > defragment the spoofed packets first just to drop them later? How does > that match the mentioned principle? > > > Theoretically it might be moved a bit earlier, > > What do you mean theoretically? It can be done practically. I have done > it and it works. Care to open a pull request then? > What I am lacking is the mechanism of dynamically > adding interface . address paired elements to the set, which comes with > Qubes This is done in the vif hotplug script: https://github.com/QubesOS/qubes-core-agent-linux/blob/main/network/vif-route-qubes#L222-L223 > , so my approach is not as flexible as the original, e.g. I can > drop hosts "pretending to be me" and bogons but that's pretty much all. > > > but I don't think it saves much processing, > > Have you made any actual tests/comparisons? In a high speed attack > (many spoofed packets) it may turn out significant. Have you measured it? I'd say it's up to ones who propose a change to justify it. (but, if the change has no downsides, I'm okay with accepting it without detailed benchmark too) > > but on the other hand you may run into some issues since not all > > packet fields are available at this stage yet. > > What issues? Which fields are necessary to drop spoofed packets? For antispoofing probably none. But other things can be added to the "prerouting" chain. Or do you mean moving just "antispoof" chain out of "prerouting" and have it hooked directly? - -- Best Regards, Marek Marczykowski-Górecki Invisible Things Lab -BEGIN PGP SIGNATURE- iQEzBAEBCAAdFiEEhrpukzGPukRmQqkK24/THMrX1ywFAmYnh6YACgkQ24/THMrX 1yyVEwf9HaVqh1fIgTeuYoTE6WK76O8CKSJaXIkm13b8br22OnvwhdzMlD74b/Y6 0nJloGncWtzn2mkGQsSH1azQTa8aroZqzqCa5GnnfiAPyXvDl4q/nM3bzw+V+SRE wISQolnH/0nPhsvUENGj2nJGVG9fR6izFxIfj/gO+6dro1GRANkHb2m2F/GIsRKu ORw5MIcprWb7t1aCrxPkCDArFt3NAsg53uxTZLsO1Tr/nH6T5GxRiPsE8U1T7pcj HWctIVJXh3JYUi4mrVVjIz9GhLSFI8Q9LykBJ+EG7vcabn5D+GN8/n5ycC1Cokx2 eJLrnfZHGQzgZ4BuN26tjQ9U0I7UDA== =2DVw -END PGP SIGNATURE- -- You received this message because you are subscribed to the Google Groups "qubes-devel" group. To unsubscribe from this group and stop receiving emails from it, send an email to qubes-devel+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/qubes-devel/ZieHpnww4gZ3MFYh%40mail-itl.
Re: [qubes-devel] Firewall antispoofing in ingress hook
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 On Mon, Apr 22, 2024 at 07:26:30PM -, qubist wrote: > Hi, > > With the current firewall, a spoofed packet can travel all the way to > the ip/ip6 hook, where it is dropped. > > Considering the general security principle to stop attacks as far as > possible, why is it not dropped early in the ingress hook instead, thus > also saving additional CPU cycles? The "antispoof" chain is hooked via the "raw" priority, which happens before all kind of connection tracking, routing etc, basically as early as firewall can see whole IP packets (not for example only their fragments). Theoretically it might be moved a bit earlier, but I don't think it saves much processing, but on the other hand you may run into some issues since not all packet fields are available at this stage yet. - -- Best Regards, Marek Marczykowski-Górecki Invisible Things Lab -BEGIN PGP SIGNATURE- iQEzBAEBCAAdFiEEhrpukzGPukRmQqkK24/THMrX1ywFAmYmy4QACgkQ24/THMrX 1yx2KQf/coLIf6whMj5JfoCF4X3E+x0liALkjPNNC7GART8HkZzCA+9w+We6bpg6 09VOWEEmMPa7PNjEFKg+frMAWT2gCFye0civCucSvmVtSmzRpZL3eWPmWZPlj8pt ITPE79fyVXBEIsvuKQaZloGFeyINQQSW64Szf+k+sWy+uTrcyV6Kx0tWpDi5KTVK TSc28ujclSWRcDCCo836lMLmd4NgBZ63C0MAdLQfzP97wwzqbFrj7FBT+r41B/ES QZE0W2zanxmA/DDoP7NOZ4BjHFSk62ueQ8xgeAyQRdNFFDwVNv2crRtjlmgolZ5z 9RgNwR9cD4/EDxhM7aP0D+fkurnaUg== =98ms -END PGP SIGNATURE- -- You received this message because you are subscribed to the Google Groups "qubes-devel" group. To unsubscribe from this group and stop receiving emails from it, send an email to qubes-devel+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/qubes-devel/ZibLhA8hJuYL9ZLJ%40mail-itl.
Re: [qubes-devel] What ensures the lack of VM IP address duplicates?
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 On Mon, Apr 22, 2024 at 07:20:08PM -, qubist wrote: > Hi, > > Which particular code is responsible for ensuring that 2 or more VMs > can never have the same IP (or IPv6) address? They are generated by default based on qubes VM ID (qid)[1], which are unique. You can see it on `qvm-ls -O name,qid,ip`. But you can also set the IP explicitly (via qvm-prefs), and then it's up to you to avoid conflicts. BTW, it's also possible hide VM's "real" IP from the VM itself using a bit of NAT magic. You can set it with `qvm-features VMNAME net.fake-ip 1.2.3.4` (or any other IP). See qvm-features man page for details. The VM will see own address as 1.2.3.4. Address set this way does not need to be unique - you can have a set of VMs that all think they have the same IP (but still, the address set in the "ip" property needs to be unique). [1] https://github.com/QubesOS/qubes-core-admin/blob/main/qubes/vm/mix/net.py#L192 - -- Best Regards, Marek Marczykowski-Górecki Invisible Things Lab -BEGIN PGP SIGNATURE- iQEzBAEBCAAdFiEEhrpukzGPukRmQqkK24/THMrX1ywFAmYmu+EACgkQ24/THMrX 1yzM1QgAio17EE6Vyh2Q5cbbbWewEcKzslW7WugCHlciSr9Z7BU2JWnDv6lLvvp3 4u1wXpkWHK8Ug90MTwzoOykX7f7hHBxtZBu5Z0iewKzKzZiMNBhPIGE6lcdva8Dx Arl+wdoXN+DPjhAxkC/DRlMHA6gKSNEZSQXw8G2cjpxTGVpp/Gpjmt9R08EFFlbh MR9RLPxT/nugz5nhKl2TTdsko+pC2FZlBGpk6czVErkbE24iAnyxG6gr1WX3/qk1 chXi3BOSQgNUUp52tc3BXPhgOcCFfwLLkxKN/IEjSXl8D7fkvinTpvHs1Kyzs/9x zyT5JTduRDmIYHGNQ+rYsBQH7cUmEg== =HCu4 -END PGP SIGNATURE- -- You received this message because you are subscribed to the Google Groups "qubes-devel" group. To unsubscribe from this group and stop receiving emails from it, send an email to qubes-devel+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/qubes-devel/Zia74U6xixfKfR9D%40mail-itl.
Re: [qubes-devel] Wrong formula in gui-configuration doc?
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 On Mon, Apr 22, 2024 at 05:18:28PM -, qubist wrote: > Thanks. Had a closer look now. > > On Mon, 22 Apr 2024 18:42:16 +0200 Marek Marczykowski-Górecki wrote: > > > What matters is the pixel count, not pixel size. > > But which pixel count? > > The pixel count reported by xrandr with the 2 screens side by side (4K > primary) is: > > user@dom0:~ > xrandr --verbose | grep "Screen 0" | sed -e 's/.*current//' -e > 's/\,.*//' > 7680 x 2160 (which means 64800 KiB for gui-videoram-min) > > which is different from 3840 * 2160 + 1920 * 1080 (i.e. 48600 KiB). > > So, the 2 formulas in the doc still give different result and it is not > clear which one is correct. It's about the pixel count as seen by the applications, which may not necessarily be the display resolution if scaling is involved. - -- Best Regards, Marek Marczykowski-Górecki Invisible Things Lab -BEGIN PGP SIGNATURE- iQEzBAEBCAAdFiEEhrpukzGPukRmQqkK24/THMrX1ywFAmYmuXQACgkQ24/THMrX 1yx0zgf/UbIX8w0XBGy0iqObsS8A/jWjtj4c3aCvLCgWfxhnWyUjyyyKZYMpEwqT lT98KrrFUynnjCW0c3ywzuR9T2ESV7NQqsoj85tRSLEnDHAG4wjgw0x6RyMbqPrN undP4RWV/sdO60a8u3t55lfxxnnbjeXmaNHNWgNtRiqAixjJiFbhlJ3FT8/NYcd9 YJQ67RRDj4GdPbCQptzYlvoepTiQ3nxkaKakPv92/tKGntIDvfyVz3tiyiSnY+zD AMXV+TIAB6pf26mwpja551WyEq3eB3iNzFIpSrrKAPD5I5kHrlNfrrqPoh+OdN5T dnugSim2/6x2ku7XP7ekW+vYapl4gA== =+ylP -END PGP SIGNATURE- -- You received this message because you are subscribed to the Google Groups "qubes-devel" group. To unsubscribe from this group and stop receiving emails from it, send an email to qubes-devel+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/qubes-devel/Zia5dA7uLNN8MDbJ%40mail-itl.
Re: [qubes-devel] Wrong formula in gui-configuration doc?
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 On Mon, Apr 22, 2024 at 04:37:54PM -, qubist wrote: > On Mon, 22 Apr 2024 15:48:02 +0200 Marek Marczykowski-Górecki wrote: > > > If you don't set the value at all, VM will allocate based on currently > > connected displays. > > Hm. This raises a few questions: > > 1. Does it mean https://www.qubes-os.org/doc/gui-configuration/ is > irrelevant/outdated? No, please read the text leading to the formula, not just the formula itself... > 2. What happens with allocation if one switches from one display setup > to another while VM(s) are running?o Read that page... > 3. What about headless VMs (no guivm)? Is video memory allocated for > them too? (thus wasting resources) No. > 4. A somewhat difficult setup: > > Due to both displays having different resolutions and because I have > been unable to find a way to set different DPI per display, currently, > it is necessary to do this when switching to the only-2K display or > dual-screen setup: > > xrandr --output DP-2 --scale 2x2 > > Without that, everything on the 2K screen is overscaled and working > side-by-side is not possible. > > Does that somehow influence the formula in the docs (because > effectively the pixels on DP-2 become x4 less)? What matters is the pixel count, not pixel size. - -- Best Regards, Marek Marczykowski-Górecki Invisible Things Lab -BEGIN PGP SIGNATURE- iQEzBAEBCAAdFiEEhrpukzGPukRmQqkK24/THMrX1ywFAmYmk2gACgkQ24/THMrX 1yxhQgf/aUFI437ylLXN16RLu64tg+wUPR6xt8Vl/xwNKdZzW5HjEp7Beuo/ew3A oa1ZdP0mIZTV/bRXRNw0wjnFYgNrb58Eq+N7whw0z5l61ZCrojIRDY7/yfOzPh9+ +x7uCUEYwytpsRftjZUwzyeq2jza3GeMup0Ql5f4C6nEOcDcJDqbGvqnx3h1V3yq DExNy+3x2M9Ag/ttWbvsHc0+uqEl+Z/tzsPrjrTHFMALwlQWn7q7QHKoHeWtkc9J 2YBWLcUeWoGV3fsZBk+hTT1DW81/buqH1ABnymVPYEQXzhJXHV868G+bahpZIEK7 yJICgk1FMilShTsIpglERVdSAr/2Zg== =XwaZ -END PGP SIGNATURE- -- You received this message because you are subscribed to the Google Groups "qubes-devel" group. To unsubscribe from this group and stop receiving emails from it, send an email to qubes-devel+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/qubes-devel/ZiaTaLen3bvxg85m%40mail-itl.
Re: [qubes-devel] Wrong formula in gui-configuration doc?
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 On Mon, Apr 22, 2024 at 01:23:11PM -, qubist wrote: > Thanks for explaining. > > If only one of the displays is currently in use (and the whole desktop > fits in it), does it make sense to reduce the the allocated video RAM > to its requirements only (the qvm feature value)? > > I am asking because this can be done through a simple script in dom0, > triggered by a shortcut key (e.g. one switches from display1 to > display2, or to dual screen and back). If you don't set the value at all, VM will allocate based on currently connected displays. But changing the value requires restarting relevant VMs, so if you care about connecting external display without restarting all VMs, then no, you cannot lower it. But if you don't care about the need to restart, then you may not need to set the value manually at all. - -- Best Regards, Marek Marczykowski-Górecki Invisible Things Lab -BEGIN PGP SIGNATURE- iQEzBAEBCAAdFiEEhrpukzGPukRmQqkK24/THMrX1ywFAmYmapIACgkQ24/THMrX 1yy7IggAi7ksQ5QEG3hrwZIAvrZWeC3gvpfhw0iyqXxpnWo87IgfjSeElT5QHh8H 8WCQmj3BahldgcSfWvJeGJ5wuPiB+qpVQeX5emydC2XfENmyG8b3lfrVIn14uxvg 4rCW6GbRP24UZmU0Ed+1WRGE/4MkFjMfTg+na8NUE7mwUJJQOoHwoJzDjvuf4/oh vm1wzwwvugieV+EsCA4c+a/qfrYWFMxwqXQbv85OzLiSCDMKW4jSf/DX4Jw2KUHn 4AJh7hy3lBcME6bjLbq+Cippkbm7xb8Jlu87uUbRIKCiJZdW5VOPuOUe8CTOH+yQ 86oB1V6CxQqMw+3cEQeC01vjS3+9ow== =am77 -END PGP SIGNATURE- -- You received this message because you are subscribed to the Google Groups "qubes-devel" group. To unsubscribe from this group and stop receiving emails from it, send an email to qubes-devel+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/qubes-devel/ZiZqkrqODC-N-TWu%40mail-itl.
Re: [qubes-devel] Wrong formula in gui-configuration doc?
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 On Mon, Apr 22, 2024 at 01:01:55PM -, qubist wrote: > On Mon, 22 Apr 2024 13:31:03 +0200 Marek Marczykowski-Górecki wrote: > > > VMs do not see nor care what display is connected. > > But what I am pasting is from dom0. Or are you saying it doesn't see it > either? The formula on https://www.qubes-os.org/doc/gui-configuration/#video-ram-adjustment-for-high-resolution-displays is about informing VMs how much memory they need to allocate for video ram. I know it's a bit unintuitive as the value is set on dom0, but it's because the value on dom0 is the default for all VMs, so you can set it once instead of on every VM separately. > It is still not clear whether if it is possible to use 10/30-bit color. You can use such display, but VMs won't see wider color space, they will still use 8 bits per color (and dom0 will covert to whatever format your display uses). - -- Best Regards, Marek Marczykowski-Górecki Invisible Things Lab -BEGIN PGP SIGNATURE- iQEzBAEBCAAdFiEEhrpukzGPukRmQqkK24/THMrX1ywFAmYmY7sACgkQ24/THMrX 1yw2SwgAie0fWITCQGUo2kOFHJePtSRF1FNAHpEe/09MNSPvdk8YXmSLhtL7AAtX L7c2kpQt21TeA6v871T4mc43pkWVY/5Q7utnQamP0gtHx/8lmXQBfZJb96J1bIWy v8e9ek/Z/2fbHD4xdYyKnfOvVon7QqTO02bNBH9cnuD+iPEzjXpe7fsIU9hZZB8u aKFcduKCuA6kGvUcE6FUzRGeRAF1JYAyr4rUBNlSnLjZ5rTz28UfBQmpgDTHoAyF nXH8aw3TfiD7DOugJGpxWph5pLXe5QYj2Pk1wuApPLL1BX4XUWstNLW/jQwrvK8G ohuSCGRZzGG1fu45Vcvcc2UcRa/RmQ== =wGMh -END PGP SIGNATURE- -- You received this message because you are subscribed to the Google Groups "qubes-devel" group. To unsubscribe from this group and stop receiving emails from it, send an email to qubes-devel+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/qubes-devel/ZiZju9bCqh64p0Dc%40mail-itl.
Re: [qubes-devel] Wrong formula in gui-configuration doc?
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 On Mon, Apr 22, 2024 at 10:38:56AM -, qubist wrote: > On Mon, 22 Apr 2024 00:01:30 +0200 Marek Marczykowski-Górecki wrote: > > > It doesn't matter what your display is using, the memory allocated in > > VM for the frame buffer is 32-bits per pixel. > > When using a 4K 10-bit display (note the bpp): > > root@dom0:~ # grep bpp /sys/kernel/debug/dri/0/i915_display_info > pipe src=3840x2160+0+0, dither=no, bpp=30 > pipe src=0x0+0+0, dither=no, bpp=0 > pipe src=0x0+0+0, dither=no, bpp=0 > > When using a 2K 8-bit display: > > root@dom0:~ # grep bpp /sys/kernel/debug/dri/0/i915_display_info > pipe src=0x0+0+0, dither=no, bpp=0 > pipe src=1920x1080+0+0, dither=no, bpp=24 > pipe src=0x0+0+0, dither=no, bpp=0 > > Also, according to 'xrandr --verbose", max bpc is 12. > > How do you read this? > > If it is always 32 bits, it would mean 2-bit alpha for 10-bit display. > Or does Qubes OS even support 10/30-bit color? VMs do not see nor care what display is connected. From the VM point of view it's always 32 bits per pixel (3x8 + 8 padding, as alpha is not supported). - -- Best Regards, Marek Marczykowski-Górecki Invisible Things Lab -BEGIN PGP SIGNATURE- iQEzBAEBCAAdFiEEhrpukzGPukRmQqkK24/THMrX1ywFAmYmSncACgkQ24/THMrX 1yxtzwf8CShXlR8j4651qFqPti6tHfL2gs9Jred4yvi3xdoZ9KLnGMZYUFoR/QN/ yZlfklge0foJHDDpOUcB+Q+Ku2SfS0Did6yUMaHQVwGH1X8zXkcLYOwIICOR2FDv 9uwdqpLEVLZK3Qmsu9RDGSs83dlub1KXzWtPaW1eMfDbxrYj5OJGjPpqsB4dT4MI YroowdXAV3+7pWt7Snb6MhRMgUKRHrXlxjLa5yl+CKZaB0eIfDMh2Dbs+0X581S9 z0j9JyUWte/BdQc6E0+EwCSpvn3qZfNazFC4hDb83J/mHlf7Uu5hT4oYBmPPsshq LztovCmualC9aA+w6Sbm0HGLMg/wkw== =Dgxd -END PGP SIGNATURE- -- You received this message because you are subscribed to the Google Groups "qubes-devel" group. To unsubscribe from this group and stop receiving emails from it, send an email to qubes-devel+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/qubes-devel/ZiZKdy_6k4bqDzbg%40mail-itl.
Re: [qubes-devel] Wrong formula in gui-configuration doc?
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 On Sun, Apr 21, 2024 at 06:30:37PM -, qubist wrote: > Hi, > > Is the formula in https://www.qubes-os.org/doc/gui-configuration/ both > wrong and incomplete? > > The correct calculation (for 8-bit displays) seems to be: > > (3840 * 2160 + 1920 * 1080) * 4 / 1024 = 40500 > > If e.g. the 4K screen is 10-bit, this means 1.25 bytes, i.e. > > ((3840 * 2160) * 1.25 + ( 1920 * 1080 )) * 4 / 1024 = 48600 > > The doc does not address 10-bit displays. It doesn't matter what your display is using, the memory allocated in VM for the frame buffer is 32-bits per pixel. - -- Best Regards, Marek Marczykowski-Górecki Invisible Things Lab -BEGIN PGP SIGNATURE- iQEzBAEBCAAdFiEEhrpukzGPukRmQqkK24/THMrX1ywFAmYljLoACgkQ24/THMrX 1yyBjQf/dtV0qWxhSK0CXl+YSe5CxeZRygU8fyWikqHFfvd3z61Um7z7YFAMyJES SzW18+VzTZEVWqjvlnX5h34L4VZ2KenXr+4kuP33vRFS0B583cLvwEAvJ8f+3ddR P5Xc4IyvZTOJ/PL4RKeLOSM5SSCh8yayPOKWntGruhny1BccIkuCKnV/npVclfR5 tJVXoUCeV/ic+/L1rVo1Y7F4qHmLFmS7QQLoiyPT6pbWTQDJwdnChrRk+fAQr8QA KGcYMZ56Omtp8Qjox6WNzo0+gYBchXrLgJEuWwEiIP0hJEqxtkGWNRygkCh3qp6S miAnRC85zcHveqiJN24GbLX3qI8csA== =Htm+ -END PGP SIGNATURE- -- You received this message because you are subscribed to the Google Groups "qubes-devel" group. To unsubscribe from this group and stop receiving emails from it, send an email to qubes-devel+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/qubes-devel/ZiWMuncw2fwM9xzE%40mail-itl.
Re: [qubes-devel] Expected behavior of empty service arguments
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256
On Fri, Apr 05, 2024 at 08:25:57PM -0400, Demi Marie Obenour wrote:
> On Sat, Apr 06, 2024 at 01:29:06AM +0200, Marek Marczykowski-Górecki wrote:
> > On Fri, Apr 05, 2024 at 02:16:32PM -0400, Demi Marie Obenour wrote:
> > > On Thu, Apr 04, 2024 at 10:43:33PM +0200, Marek Marczykowski-Górecki
> > > wrote:
> > > > On Thu, Apr 04, 2024 at 03:44:40PM -0400, Demi Marie Obenour wrote:
> > > > > Should an empty service argument (qubes.Service+) always be the same
> > > > > as
> > > > > no argument at all (qubes.Service)? Right now, they are the same when
> > > > > coming from a VM, but not when coming from dom0: qubes.Service from
> > > > > dom0
> > > > > will not search for /etc/qubes-rpc/qubes.Service+, but qubes.Service+
> > > > > will.
> > > >
> > > > I'd say they should behave the same - the "qubes.Service" call should
> > > > search for /etc/qubes-rpc/qubes.Service+ first.
> > >
> > > Is the "qubes.Service" call actually valid to make? dom0 certainly
> > > makes such calls right now, but I'm wondering if that is a bug.
> >
> > That's a very good question. The argument (including "+") used to be
> > completely optional, and we did distinguished "no argument" from "empty
> > argument" in some places. But it was confusing (especially when writing
> > policy for such cases) and was removed in R4.0 for VM-originating calls.
> > For dom0-originating calls, policy concern doesn't apply, as those
> > aren't going through it. But for consistency it might be a good idea to
> > always include "+" anyway.
>
> I'm inclined to agree.
>
> > > In that
> > > case, dom0 should be fixed to always include the "+". That can be done
> > > in either Python (easy, but requires changing multiple callers) or in
> > > qrexec-client itself.
> >
> > I'd say it's safer to change in Python. qrexec-client normally doesn't
> > parse the command it sends, and changing the command there may lead to
> > some unintended side effects or bugs. But also changing there would make
> > it quite hard to make some exception if turned out necessary.
> > On the Python side, it isn't that many places - one in core-admin, one
> > in core-admin-client and one in core-qrexec. Plus a few in various
> > tests. There are also not that many manual qrexec-client calls, I see
> > them in app-linux-input-proxy and gui-daemon.
>
> Changing it in qrexec-client turned out to be quite easy, but it also
> raises concerns about the same command being parsed different ways (due
> to e.g. version skew), and so I decided to not go that route. It also
> indeed makes an exception impossible to add without some sort of
> out-of-band signalling, such as a new command-line option.
>
> > Anyway, technically this is an API change and as such I'd avoid doing it
> > as R4.2 update. Linux agent should have no issue with this, but other
> > implementations may. For example I see qubes-mirage-firewall is looking
> > for "QUBESRPC qubes.SetDateTime dom0" explicitly:
> > https://github.com/mirage/qubes-mirage-firewall/blob/main/command.ml#L25
>
> By "this", do you mean changing the API calls made by dom0 to include
> the "+", or changing the way the Linux agent interprets calls that do
> not include the "+"?
I mean changing how dom0 makes calls.
> > > Also, should socket-based services receive what was actually sent
> > > ("qubes.Service") or what was used for lookup ("qubes.Service+")? The
> > > same goes for executable services and the QREXEC_SERVICE_FULL_NAME
> > > environment variable. Right now I fix up QREXEC_SERVICE_FULL_NAME but
> > > not the metadata passed to socket-based services.
> >
> > I'd say socket-based services should receive what was actually sent.
>
> That makes sense, and is actually simpler to implement. What about
> QREXEC_SERVICE_FULL_NAME? That's the analog for executable services.
> By analogy to socket-based services, it makes sense to pass what was
> actually sent here too, but I currently add a trailing "+" if none is
> present.
This also should IMO include the name as was sent to the qrexec agent.
- --
Best Regards,
Marek Marczykowski-Górecki
Invisible Things Lab
-BEGIN PGP SIGNATURE-
iQEzBAEBCAAdFiEEhrpukzGPukRmQqkK24/THMrX1ywFAmYQmAgACgkQ24/THMrX
1yw9fAf/TttfORQja9JZvDE0HELVhWDNKf3ZBRIZ8Q8DJJT9p9AM5/A/2Ifp20k7
csQ43n5YbN03b7Y7wkhJFgHpL3WYiGH94gg7hqr7L8U4jba7Q3Rn1C7KhMdT/iou
fRQCwmGHgh6UJiwPjlhnTU+Jdjv8PYhd4SmPcu7G/zlHOS1Ukim6W2XtfYe8efgP
zMOwGB3pjCaZMyZKWj+QTP56IBGzaHSwsBJcmF3Ng27Z84iu2I3+b6zPucm52Ab+
oPPiW3w9ABDDZ00Wqydhf+TF3zHUMRqxCM9oYdPFGZbcEqMAOvG9xvq2myvHGVQY
xL6rFzIlwnFDSkn6ZxwNZ6j4rFXBtA==
=fDP4
-END PGP SIGNATURE-
--
You received this message because you are subscribed to the Google Groups
"qubes-devel" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to qubes-devel+unsubscr...@googlegroups.com.
To view this discussion on the web visit
https://groups.google.com/d/msgid/qubes-devel/ZhCYCDxD9o3-X5Zx%40mail-itl.
Re: [qubes-devel] Expected behavior of empty service arguments
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256
On Fri, Apr 05, 2024 at 02:16:32PM -0400, Demi Marie Obenour wrote:
> On Thu, Apr 04, 2024 at 10:43:33PM +0200, Marek Marczykowski-Górecki wrote:
> > On Thu, Apr 04, 2024 at 03:44:40PM -0400, Demi Marie Obenour wrote:
> > > Should an empty service argument (qubes.Service+) always be the same as
> > > no argument at all (qubes.Service)? Right now, they are the same when
> > > coming from a VM, but not when coming from dom0: qubes.Service from dom0
> > > will not search for /etc/qubes-rpc/qubes.Service+, but qubes.Service+
> > > will.
> >
> > I'd say they should behave the same - the "qubes.Service" call should
> > search for /etc/qubes-rpc/qubes.Service+ first.
>
> Is the "qubes.Service" call actually valid to make? dom0 certainly
> makes such calls right now, but I'm wondering if that is a bug.
That's a very good question. The argument (including "+") used to be
completely optional, and we did distinguished "no argument" from "empty
argument" in some places. But it was confusing (especially when writing
policy for such cases) and was removed in R4.0 for VM-originating calls.
For dom0-originating calls, policy concern doesn't apply, as those
aren't going through it. But for consistency it might be a good idea to
always include "+" anyway.
> In that
> case, dom0 should be fixed to always include the "+". That can be done
> in either Python (easy, but requires changing multiple callers) or in
> qrexec-client itself.
I'd say it's safer to change in Python. qrexec-client normally doesn't
parse the command it sends, and changing the command there may lead to
some unintended side effects or bugs. But also changing there would make
it quite hard to make some exception if turned out necessary.
On the Python side, it isn't that many places - one in core-admin, one
in core-admin-client and one in core-qrexec. Plus a few in various
tests. There are also not that many manual qrexec-client calls, I see
them in app-linux-input-proxy and gui-daemon.
Anyway, technically this is an API change and as such I'd avoid doing it
as R4.2 update. Linux agent should have no issue with this, but other
implementations may. For example I see qubes-mirage-firewall is looking
for "QUBESRPC qubes.SetDateTime dom0" explicitly:
https://github.com/mirage/qubes-mirage-firewall/blob/main/command.ml#L25
> Also, should socket-based services receive what was actually sent
> ("qubes.Service") or what was used for lookup ("qubes.Service+")? The
> same goes for executable services and the QREXEC_SERVICE_FULL_NAME
> environment variable. Right now I fix up QREXEC_SERVICE_FULL_NAME but
> not the metadata passed to socket-based services.
I'd say socket-based services should receive what was actually sent.
- --
Best Regards,
Marek Marczykowski-Górecki
Invisible Things Lab
-BEGIN PGP SIGNATURE-
iQEzBAEBCAAdFiEEhrpukzGPukRmQqkK24/THMrX1ywFAmYQiUIACgkQ24/THMrX
1yynWQf/QpvzpZ3kCiC1nMidobCjAY/rhtrramEpAuCpceEB7JxHj9vAfnJlify8
xag7PgRiIIZ31+eKxZrYfoW/QBOPiX9tU3/bhtUocjXqS6l0UDiSIA9UMDDqAl0w
UJainDUIdzRtH/EPXWjcr48FM3jZmKQPWOAmXteNZfWcmYWH6KtwEaHkyxZ2lLM0
zLcDnWrEykS8DbZpTbClxQ8S4vq8BcYKH1ULMAurmNE3sToJC858Sf4bp8QPvfLN
GU2ndsSMUsiHB/1mc7cazjD4DPTqpmy+Od98Cndd08JMpoLPZ6dqqwLh5C8hTQ/W
FcDghMPqLIutq4p35O2x2cqE13kOGQ==
=MM1I
-END PGP SIGNATURE-
--
You received this message because you are subscribed to the Google Groups
"qubes-devel" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to qubes-devel+unsubscr...@googlegroups.com.
To view this discussion on the web visit
https://groups.google.com/d/msgid/qubes-devel/ZhCJQgWWtKihPusv%40mail-itl.
Re: [qubes-devel] Expected behavior of empty service arguments
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 On Thu, Apr 04, 2024 at 03:44:40PM -0400, Demi Marie Obenour wrote: > Should an empty service argument (qubes.Service+) always be the same as > no argument at all (qubes.Service)? Right now, they are the same when > coming from a VM, but not when coming from dom0: qubes.Service from dom0 > will not search for /etc/qubes-rpc/qubes.Service+, but qubes.Service+ > will. I'd say they should behave the same - the "qubes.Service" call should search for /etc/qubes-rpc/qubes.Service+ first. - -- Best Regards, Marek Marczykowski-Górecki Invisible Things Lab -BEGIN PGP SIGNATURE- iQEzBAEBCAAdFiEEhrpukzGPukRmQqkK24/THMrX1ywFAmYPEPUACgkQ24/THMrX 1ywpTgf/ShJpgfb+JaByYYeMur5PGNqaDqwvh79QrTjPTJCh0omrw0NvWcctcQGU o7YlEZ0eymAzF5iHDD2vG4MCwI0+xovaJrjV5LiOsauBCe5Jc1rRYTLS2aaK/Ysl b8gCUgst5VteLseGj7sNNu3LBPLTFljWc6pPg09c3sGB7wB1VH+dmPSfeV98tWX2 m3RrHP0jLUxDcmaJyEhcuDZUAOCO0g8/mVPaDe2qtBrvawpQFela0Cp/h9aP/+LH mgc+1n+fZC/Bg8u2AbJsadGd+bJ7MOt6Jrgcghn8rAO3Tkzc7OsZ+Nv7TBboYYe/ MQSJ/RoVT7/RCcdvl3kWK8KESov2Lw== =0j62 -END PGP SIGNATURE- -- You received this message because you are subscribed to the Google Groups "qubes-devel" group. To unsubscribe from this group and stop receiving emails from it, send an email to qubes-devel+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/qubes-devel/Zg8Q9ZmEuvcscvEx%40mail-itl.
Re: [qubes-devel] Why does Qubes firewall separate IPv4 and IPv6?
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 On Mon, Mar 25, 2024 at 12:34:18PM -, qubist wrote: > On Mon, 25 Mar 2024 12:45:17 +0100 Marek Marczykowski-Górecki wrote: > > > IMO the main advantage of the single table approach is purely > > port-based rules (UDP or TCP), but the default firewall doesn't have > > many of them. They may be relevant for custom-input chain (but not > > always - sometimes you might want to use IP address in those too), > > and rarely for custom-forward. > > What do you mean? Using an IP address is possible in inet table too. Yes, but you need separate rules for IPv4 and IPv6 anyway, so the benefit of combined table is minimal. - -- Best Regards, Marek Marczykowski-Górecki Invisible Things Lab -BEGIN PGP SIGNATURE- iQEzBAEBCAAdFiEEhrpukzGPukRmQqkK24/THMrX1ywFAmYBcogACgkQ24/THMrX 1ywrjAf/Uc7SvayVEarHjEKQ9bZDqCPp0+5bOYDFVhSgvLYzVjchku/teYehAtVJ Pe1LMrdeawIDUk2va3VCldS5zpjEoABDG68a2e4AR3QSFbw3pT4QlpH/0FiTOD1j aDjs2INgChAFi0hinw7oDt2H89IFc0ZQcFZhYhYR/3R8oZEJDoMAhazP4cAZnkI+ gaHCuptr0BP8nNVRsj6pjPLm779PD2821uF/jIKZIW+hTuG5xvmIQ9/d0XPvC6th APbkUUzFOeII+D0sHO7F6/SlrBxMV6iqdoUwOG7sWKGUTW5FdgA92/OOOl6vGj8C xllZmVSwKkMedB41HnMkS5eLHiB+IA== =LcEW -END PGP SIGNATURE- -- You received this message because you are subscribed to the Google Groups "qubes-devel" group. To unsubscribe from this group and stop receiving emails from it, send an email to qubes-devel+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/qubes-devel/ZgFyiPSajbxi2wxL%40mail-itl.
Re: [qubes-devel] Why does Qubes firewall separate IPv4 and IPv6?
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 On Sat, Mar 23, 2024 at 07:55:17PM -, qubist wrote: > On Sat, 23 Mar 2024 13:05:39 + 'unman' via qubes-devel wrote: > > > However, the 4 and 6 rulesets are distinct and although they could be > > merged to a single table, the result would not be any cleaner. While > > there is some duplication, there are also distinctions. > > Sometimes keeping separate tables allows for greater clarity. > > I am not quite sure what you mean by cleaner and greater clarity. > Compare the 2 files I am attaching. > > separate.nft - as it is currently in Qubes > single.nft - a quick attempt to merge them into a single inet table > > separate - 133 lines > single - 82 lines > > I have not made any performance comparison but in regards to > simplicity, single.nft looks simpler to me. Perhaps it can be optimized > even more, e.g. dropping invalid packets in early in prerouting hook > instead of letting them to input. > > What do you think? Has any optimization been considered? A single table is surely shorter, but TBH I'm not sure if it's clearer. Some rules needs to be duplicated for v4 and v6, some don't. IMO the main advantage of the single table approach is purely port-based rules (UDP or TCP), but the default firewall doesn't have many of them. They may be relevant for custom-input chain (but not always - sometimes you might want to use IP address in those too), and rarely for custom-forward. In any case, changing it now is not an option. It would mean changing the API for custom rules, which was a huge pain for users migrating to R4.2, and we are not going to do that _again_ now. - -- Best Regards, Marek Marczykowski-Górecki Invisible Things Lab -BEGIN PGP SIGNATURE- iQEzBAEBCAAdFiEEhrpukzGPukRmQqkK24/THMrX1ywFAmYBY80ACgkQ24/THMrX 1yzebgf/dkFXbsl7FYfgeqPEJTZ/HMPWieXum7vI06FpuLlHncPMhbJ833prtAvK CIZF/iEEOsngyiGT0VaH45NO3H4QBDftikwDQ3eB91+qJ792zcmaiuOj9LYStka4 XdsMhCbZsH8PeVfU36z7DGlZZ0lay1dAgqH4lVYu+LAA55mNFB6CqHLKq/APnrk9 Iopuz8m7AA8yEQ4lrAvYtFY3OpKQpKv0VZhDTtrILj0io7JdTzWNAbD0EFJmr7po YW3j+kuRCTEUK0c4wD00mU5ZAytEdjgZuKQSTnfbEbrzOxSOvY+6E5a4B+SnqA0D BciowS1par9BQDTZUsKnYPUIa0qySg== =CtoI -END PGP SIGNATURE- -- You received this message because you are subscribed to the Google Groups "qubes-devel" group. To unsubscribe from this group and stop receiving emails from it, send an email to qubes-devel+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/qubes-devel/ZgFjzUYGEWwhdevV%40mail-itl.
Re: [qubes-devel] qubes-vmm-xen Patch Organization
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 On Wed, Mar 13, 2024 at 07:31:10PM +, 'Skyler Ferris' via qubes-devel wrote: > Hello, > > I am confused about a change made in yesterday's set of commits and I am > hoping you can help me understand. Among other changes, the patch formerly > known as 0500-xsa449.patch was renamed to > 0315-pci-fail-device-assignment-if-phantom-functions-cann.patch. The patch > declaration was also moved to the corresponding section in xen.spec.in (from > "Security Fixes" to "Backports"). This confuses me because I do not > understand the patch to be a backport (the [upstream XSA > advisory](https://xenbits.xen.org/xsa/advisory-449.html) lists 4.17 as the > target branch for this patch) and it is still a security fix regardless. But > I do not know why the patches are organized this way (eg, why it is useful to > list backports and security fixes in separate places to begin with) and > perhaps if I did the reason for this reorganization would be obvious. This is to help with updating the patches. The "security fixes" section is about individual patches, usually taken directly from the security advisories. At the point of adding them to the qubes-vmm-xen repository, they aren't in upstream git yet. The patches taken from stable-4.17 branch into "backports" are directly from upstream git repository - some of them are security relevant, but some are plain bug fixes. It doesn't make sense to split such bulk import into categories, especially since order of patches is important. When we update to a newer Xen version, patches needs to be checked if they are still applicable - keeping all patches that are taken from upstream git together makes the process much easier. You can see it in the commit that moves it: https://github.com/QubesOS/qubes-vmm-xen/pull/181/commits/f22008ff1f41a91213383b6ce532548bf2c26b4c - -- Best Regards, Marek Marczykowski-Górecki Invisible Things Lab -BEGIN PGP SIGNATURE- iQEzBAEBCAAdFiEEhrpukzGPukRmQqkK24/THMrX1ywFAmXyFC0ACgkQ24/THMrX 1yzhbQf9HVMqU/Nb7OIYASapFSqVUb2b7nrz9qlO+oJ/jC4X7r4xp8zhgVV6z9Br cvKnrtlGpZlA6wPbPGO75JJ7qQillchXXoszD8i+rW/Ev8TolUZrQZBo7CQSsJr+ SIhA1jy3marucyQ8qMD5WmqV+xKteOgtec4zejCn4MmWAX7aS7W8Wb7QVjPv0NXL rvIrnGbKTmgBjlpAdL1qGWVxQZ83vytHXjnnhx+klx2hpkp0wUjnR4ScqVtTNoCz WFdmOkcVDrfPpMHrm6T7Uj/aOLTxdTI4/Jwe4BQ5EGhZT9spJT41OsdVJr1vfWrD ctQacxSBBS8pcUx15OxaMqz+e2yfaQ== =CR4j -END PGP SIGNATURE- -- You received this message because you are subscribed to the Google Groups "qubes-devel" group. To unsubscribe from this group and stop receiving emails from it, send an email to qubes-devel+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/qubes-devel/ZfIULUh06ZK2NNaD%40mail-itl.
Re: [qubes-devel] Minimal minimal templates?
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 On Wed, Mar 06, 2024 at 11:59:41AM +, 'unman' via qubes-devel wrote: > There's a recent issues on GitHub (#8980) about removing "non-essential" > packages from the Debian minimal template. > > The argument is that minimal templates should contain only "vital packages". > OP argues that a minimal system is one from which nothing can be removed > without breaking anything else, and therefore the minimal templates > should be trimmed accordingly. > > Debian has the concepts of minbase and base systems. > Minbase is a variant in debootstrap - it installs only essential > packages and apt. > The base system, or core installation, consists of essential packages, > and those tagged as required or important. > > The Debian minimal template is a core system, with some Qubes packages > installed. > In my view the minimal template contains a base system - it contains > packages that any user of Debian would expect to find installed. > > The docs say that "The minimal templates are lightweight versions of > their standard template counterparts. They have only the most vital > packages installed, including a minimal X and xterm installation." > > It may be that Qubes wants to ship a micro template, with only selected > packages installed, as well as the existing minimal templates. Or trim > down minimal templates to minbase, or smaller. > In either case, we would need to decide what packages should be included. > Any decision should be applied for all official templates. > > (I should say that building with minbase in debootstrap makes very > little difference once Qubes packages are installed, and that not all > packages correctly set out dependencies on packages that are assumed o > be present.) > > Thoughts would be appreciated. Generally, I think minimal template should be as minimal as possible, while still allowing reasonable easy customization. The latter especially means: - - working package manager (thanks to updates proxy, it doesn't require all kind of networking packages) - - some terminal emulator - - being able to target with salt (or ansible in the future) The last two are debatable. Terminal emulator may not be strictly required since there is qvm-console-dispvm. And also salt is rather arbitrary choice here, but IMO since minimal templates in practice must be customized to be useful, being friendly to automating this customization makes sense (BTW, this is currently broken in Fedora minimal templates). If there is some smaller base Debian variant to start from, IMHO it's worth a try. Currently the main difference is that minimal template skips installing "standard" task: https://github.com/QubesOS/qubes-builder-debian/blob/main/template_debian/02_install_groups.sh#L45-L54 and also there is a smaller list of packages to be installed: https://github.com/QubesOS/qubes-builder-debian/blob/main/template_debian/packages_minimal.list many of the latter list probably can be removed. If some of those are actually required by other packages, it should be set in package dependencies. And if that's isn't the case, it's a bug to be fixed. Whether to actively remove packages that were installed automatically but aren't "vital" is another question. I suspect it might be quite fragile (something that wasn't essential before may become essential at some point, and thus removing will break stuff). I'd prefer the approach that prevents installing non-essential packages in the first place, so dependencies still can do their job. Minimal templates are built with "no-recommends" option[2] already. But maybe there is some place that doesn't use that properly and some "recommends" (not "depends") packages are installed anyway? [2] https://github.com/QubesOS/qubes-release-configs/blob/main/R4.2/qubes-os-r4.2-templates-itl.yml#L131 - -- Best Regards, Marek Marczykowski-Górecki Invisible Things Lab -BEGIN PGP SIGNATURE- iQEzBAEBCAAdFiEEhrpukzGPukRmQqkK24/THMrX1ywFAmXocJAACgkQ24/THMrX 1yzREAf+K3SnbpqCuQx8zyVyVZP1GqYpcvZ4yAn1+KMisiinpI1/x+3/wmOdP3f7 9AyuNBJ3wVBMgliYWAtQMLdZ2sqyS41KTEQd6BwVvuK9qjYp6cO72GdUdvK1WWbK 1cw6nq0gux+livKIbXjxgyjloABrGmzfG6F5/4QAi/Ce7TrED1DqlTW5RSjqORRj N8LWY0wZ+oyPn/fTNnNGh4KxZb5Ps+T8fHloK1E2A+N6mcBPkDaAsqvZ0+x2lqCR FxVgygFjoEo3LJBtjNamzg7ELjwWGDDXoKaYO0AfqIt93i04YNE3TtXh/YTH/QA+ 1omKuMoRjIj/0vJV+ACI/mnTYVyvfw== =tZfX -END PGP SIGNATURE- -- You received this message because you are subscribed to the Google Groups "qubes-devel" group. To unsubscribe from this group and stop receiving emails from it, send an email to qubes-devel+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/qubes-devel/ZehwkPMa_2lkdnWv%40mail-itl.
Re: [qubes-devel] Is QEMU in dom0 fine if it emulates zero devices?
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 On Sat, Mar 02, 2024 at 12:53:21PM -0500, Demi Marie Obenour wrote: > On Sat, Mar 02, 2024 at 01:54:33PM +0100, Marek Marczykowski-Górecki wrote: > > On Sat, Mar 02, 2024 at 10:58:26AM +0100, Simon Gaiser wrote: > > > Demi Marie Obenour: > > > > Is QEMU in dom0 fine if it emulates zero devices? I’m specifically > > > > wondering about a configuration in which the only emulated device is a > > > > virtio GPU, which will be emulated via crosvm’s vhost-user-gpu support. > > > > This might require some QEMU patches to support the extra commands that > > > > are needed for blob devices. In this mode, QEMU should be able to run > > > > under a strict seccomp allowlist and does not need to interact with the > > > > GPU itself. > > > > > > What would be QEMU doing at all in this case? > > > > > > If we can isolate it similar (or better) than the current stubdomain > > > solution running it in dom0 is certainly an option. > > > > > > One thing to look at is how the required interface towards Xen looks like > > > in this case. AFAIK running QEMU in a Linux sandbox is already supported, > > > so that interface is probably already prepared for this case. > > > > > > How would the normal device emulation required for a HVM work in that > > > case? Or are we talking PVH? But the later normally has no QEMU at all, > > > so not sure if that would work without major work on the Xen side. > > > > The thing we want to avoid the most in dom0-based QEMU is emulation of > > all the base devices (PCI root complex, chipset, various legacy devices > > etc). This is an old code base, and also historically some emulators > > were reachable for attacks even if given device was configured to be > > disabled (see VENOM bug). Xen supports ioreq servers API where emulator > > can manage a specific PCI (or other) device and won't receive > > communication directed at other devices at all (so, much less risk of > > unintended attack surface). But it needs to be used by that emulator > > this way (instead of claiming the whole PCI bus, which is what QEMU does > > right now). > > I believe this means that QEMU in dom0 is not an option right now, even > if vhost-user-gpu is employed. Cloud Hypervisor + vhost-user-gpu should > work once Cloud Hypervisor is ported to Xen, though, and there has been > interest in this from the Cloud Hypervisor side. > > > This touches another topic - what is needed to have virtio for a VM. > > Preferably for a PVH domain (so, without all the emulated legacy > > devices). IIUC currently virtio in Xen works with HVM only, right? > > There is a vPCI that handles PCI root complex emulation in Xen, and it's > > used for PVH dom0. AFAIK this code should allow emulation of individual > > PCI devices by separate ioreq servers, without all the legacy stuff, and > > also is a prerequisite for PCI passthrough to PVH. But I'm not sure what > > is the state of vPCI supporting non-dom0 VMs, and how much work is > > still needed for virtio for PVH (and also PCI passthrough for PVH, which > > is another thing interesting for us). Or maybe some of it is completed > > already? > > I think it is being worked on, but I’m not sure it is security supported > upstream yet. Even if it was, it seems to move a lot of complexity to > the most privileged context. Is there a reason to believe Xen’s vPCI is > going to be more secure? The Xen's vPCI is mostly about arbitrating which access goes where (to the real device in case of passthorugh, to some emulator via ioreq protocol etc). It doesn't emulate all kind of devices that QEMU does, it only emulates enough to perform this arbitration. - -- Best Regards, Marek Marczykowski-Górecki Invisible Things Lab -BEGIN PGP SIGNATURE- iQEzBAEBCAAdFiEEhrpukzGPukRmQqkK24/THMrX1ywFAmXjegoACgkQ24/THMrX 1yyV7Qf/VZzvpjJRhaVJTT5p2KEsbndG6+vPT8aNIl3sQgJgXX7yjJjD6+ZDwlK4 klIIAGWXP7ex0/sTw9fTO9bufafsPNpVb5QKkOk7LY6jPdD13XnFVa/3p+gpEwzU yb2HajTmDCGU2Irsv8luSp6ojf5BszVJYIvggoVa/Unq39w1VXPj038XotHEW9ud 6oEfUmYsZVSnKqxmVc63/BOQMtECotsQrCT1B81unBAgXflqoTsk/zSP8VIzrDBS F8MViA9BqjOEMhS4d1zSpwb/3VRGXwyKN/PM2rXNiOYNunViXZ8lJYzennJkcEbC OBVt6So9gE32voIIuOQGfg3/fgXu1g== =NWXw -END PGP SIGNATURE- -- You received this message because you are subscribed to the Google Groups "qubes-devel" group. To unsubscribe from this group and stop receiving emails from it, send an email to qubes-devel+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/qubes-devel/ZeN6CkBRa2cR_ILi%40mail-itl.
Re: [qubes-devel] Status of Qubes builder v1
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 On Sat, Mar 02, 2024 at 08:49:49AM +, 'unman' via qubes-devel wrote: > What is the status of builder v1? > Is it deprecated or obsolete? > Is builder v2 now the standard, recommended, (only?), way of building > Qubes and Qubes elements? > > numerous bugs and documentation issues rest on this. Building Qubes 4.1 is supported only via builder v1. Building Qubes 4.2 is supported by both builder v1 and v2 (official packages are built using v2). Future Qubes versions will be supported only via builder v2. - -- Best Regards, Marek Marczykowski-Górecki Invisible Things Lab -BEGIN PGP SIGNATURE- iQEzBAEBCAAdFiEEhrpukzGPukRmQqkK24/THMrX1ywFAmXjIhMACgkQ24/THMrX 1yzxTQf/c9hEJy0mOYJ+YfoXpV3I7oO77OgwSeoCrWhk8skGxBbeZuyIdchhvOWw rLDa57Hr+UTmmtSb+N62E6ZEkSn3arvCCMingOIGYlvY0IYlGdXrr7XLN4MnMlbd i1Cn6febOghIqB6nXwrNQhx/PHTt7hJj6Eoq3pzs35mLwA4aqdMzQqMI/M+FFD42 NuX8EoGDMg8M/8xHpevDPQO2e8prtYXELPScBxR1D1KU7bEP2SVu7rd1IBvrqZcg /lgpvM7x4ed/9uOVP2bCJMrEyp8qvML769aBmQAEkhD7mmt7hJIkaZy4OC2wEQn5 jNN6D9B9a9GuawANyXTg7EdbLVVyvA== =oPD0 -END PGP SIGNATURE- -- You received this message because you are subscribed to the Google Groups "qubes-devel" group. To unsubscribe from this group and stop receiving emails from it, send an email to qubes-devel+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/qubes-devel/ZeMiE8Q9vILgaQw_%40mail-itl.
Re: [qubes-devel] Is QEMU in dom0 fine if it emulates zero devices?
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 On Sat, Mar 02, 2024 at 10:58:26AM +0100, Simon Gaiser wrote: > Demi Marie Obenour: > > Is QEMU in dom0 fine if it emulates zero devices? I’m specifically > > wondering about a configuration in which the only emulated device is a > > virtio GPU, which will be emulated via crosvm’s vhost-user-gpu support. > > This might require some QEMU patches to support the extra commands that > > are needed for blob devices. In this mode, QEMU should be able to run > > under a strict seccomp allowlist and does not need to interact with the > > GPU itself. > > What would be QEMU doing at all in this case? > > If we can isolate it similar (or better) than the current stubdomain > solution running it in dom0 is certainly an option. > > One thing to look at is how the required interface towards Xen looks like > in this case. AFAIK running QEMU in a Linux sandbox is already supported, > so that interface is probably already prepared for this case. > > How would the normal device emulation required for a HVM work in that > case? Or are we talking PVH? But the later normally has no QEMU at all, > so not sure if that would work without major work on the Xen side. The thing we want to avoid the most in dom0-based QEMU is emulation of all the base devices (PCI root complex, chipset, various legacy devices etc). This is an old code base, and also historically some emulators were reachable for attacks even if given device was configured to be disabled (see VENOM bug). Xen supports ioreq servers API where emulator can manage a specific PCI (or other) device and won't receive communication directed at other devices at all (so, much less risk of unintended attack surface). But it needs to be used by that emulator this way (instead of claiming the whole PCI bus, which is what QEMU does right now). This touches another topic - what is needed to have virtio for a VM. Preferably for a PVH domain (so, without all the emulated legacy devices). IIUC currently virtio in Xen works with HVM only, right? There is a vPCI that handles PCI root complex emulation in Xen, and it's used for PVH dom0. AFAIK this code should allow emulation of individual PCI devices by separate ioreq servers, without all the legacy stuff, and also is a prerequisite for PCI passthrough to PVH. But I'm not sure what is the state of vPCI supporting non-dom0 VMs, and how much work is still needed for virtio for PVH (and also PCI passthrough for PVH, which is another thing interesting for us). Or maybe some of it is completed already? - -- Best Regards, Marek Marczykowski-Górecki Invisible Things Lab -BEGIN PGP SIGNATURE- iQEzBAEBCAAdFiEEhrpukzGPukRmQqkK24/THMrX1ywFAmXjIYkACgkQ24/THMrX 1yzYSwf7BVnQnu7Nafdm0KE8S3f8dxNg/SEmAkmlr1P99Uic2ASOU/401ni9TTyc EoilwiGZNtlAL1SZQyzWYE6OOeSqEnG1a4FQP9cBs2VnzamTYKdYANG3F8WV0iV5 Xhn/dbcZMTkzeAvH5kv9FO/xq6D5WoVPKhZaF837lzMyQg49ZxdOTNydiR2n98WP I9no9mQZ3y1S5oYZdibClb8w5kZB4kBM1WSX3smw//3+oMbrxMB56oB2nYDzawgo BooSEuyCUyuxzq+qLg/bnCzixWVN5HNcVLedAWjv2i+xrQnjD1Q/vbhK4Ls2ajgO RWGZpSfWRXpdo/yjna7PYTmoNX0BgA== =EMoo -END PGP SIGNATURE- -- You received this message because you are subscribed to the Google Groups "qubes-devel" group. To unsubscribe from this group and stop receiving emails from it, send an email to qubes-devel+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/qubes-devel/ZeMhid01SsUFnAr_%40mail-itl.
Re: [qubes-devel] Admin privileges of a GuiVM
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 On Wed, Feb 21, 2024 at 11:41:54PM -0500, Demi Marie Obenour wrote: > On Thu, Feb 22, 2024 at 04:24:49AM +0100, Marek Marczykowski-Górecki wrote: > > On Mon, Feb 19, 2024 at 10:47:45PM +0100, PeakUnshift wrote: > > > Hello, > > > > > > When using a GuiVM, several issues appear regarding permission errors. I > > > created a topic on the forum and opened an issue: > > > - > > > https://forum.qubes-os.org/t/grant-full-admin-privileges-to-sys-gui-sys-gui-gpu/24368 > > > - https://github.com/QubesOS/qubes-issues/issues/8934 > > > > > > My message here is more general about what privileges a GuiVM should have. > > > Currently: > > > - dom0 is not accessible from sys-gui, but we can CTRL+ALT+F2 to access > > > tty > > > or login back to XFCE's dom0 session. > > > - there is no way to access dom0 from sys-gui-gpu because the GPU is not > > > attached to it. > > > > > > Then, we need a way to get full admin privileges from the GuiVM: > > > - Should we grant full admin privileges to the GuiVM? > > > - Should we grand full admin privileges to a dedicated AdminVM? > > > - Should we create multiple adminVMs for different tasks, but all > > > together, > > > give full privileges? > > > - Is it just a question of policies or is there other development needed > > > in > > > order to execute dom0 commands from a domU? > > > > > > I'm aware that the GuiVM is still highly experimental, I try to gather > > > information in order to clarify the correct path to follow and thus help > > > future contributions. > > > > Generally, the goal is to have specific qrexec services for everything > > that needs dom0 action, and then grant access to those, based on some > > sensible policy (in default GuiVM case, user controlling GuiVM is fully > > in control, but there can be a case where there is separate management > > VM for some tasks). It shouldn't be necessary to access dom0 shell at > > all. In the current implementation, several of those services are > > missing. We collect them in this project: > > https://github.com/orgs/QubesOS/projects/15/views/1 > > > > So, any missing part should get a ticket that we can add to the project > > above. In the meantime, some access to dom0 shell is likely useful - > > for sys-gui you found it already, but for sys-gui-gpu probably the > > easiest way is to setup something like qubes.VMShell. But remember it > > gives sys-gui-gpu unlimited access to dom0 - be careful what you install > > in the template for that qube and in the qube itself. > > I will add that certain parts of the Admin API (such as modifying qrexec > policy) can be used to obtain full shell access in dom0. This is by > design, but is obviously undesirable in certain situations. > > Is it possible to have a sys-gui that is powerful enough to be usable, > but which is still considered to be strongly isolated from dom0? Or > does this require features that have not been implemented? Currently several parts are missing (see above project), but the goal is to make it possible. I'd like to have enough integration to support two scenarios: 1. Full control by the user of GuiVM, including all kind of configuration changes. This doesn't add much security boundary between dom0 and GuiVM, but should still allow nice things: - much smaller dom0 (no desktop environment there), possibly base OS immutable with dm-verity - updates of desktop environment not tied to updating dom0 2. Limited user - any pre-made qube can be used normally, but user cannot make changes to any configuration. Possibly cannot also get shell in templates (only dedicated service to install updates, if not completely automatic). Configuration can be changed through dedicated management vm. There are a lot of options in between, mixed scenarios etc, but some may require extra features that are out of scope for now. - -- Best Regards, Marek Marczykowski-Górecki Invisible Things Lab -BEGIN PGP SIGNATURE- iQEzBAEBCAAdFiEEhrpukzGPukRmQqkK24/THMrX1ywFAmXXN/UACgkQ24/THMrX 1yz01Qf9HAIHlfzW5/21AbUl7zj413z30lwtzswlSYs21erB3OwhotTZdna4IR74 T3qzc3DWfWQdAep8z7kHwxgftXCZXE0b6heEojcQ7aGGbsTiIv2mx4ZVt87hlyQS 456og0xGTHHFNt0ln889v5Trx+HhAR6b9LH1tyUj0aLkdczU5H/YimlnTB0zzz0V PJ70dhBCz0YtMpzEXDdYdeGYIes2W1mmI2CeeDaCoiWtfWRP46wOFsFmDYsZywZi CGHdL3rObybiCC/LlVi8jobTr46SeXLoPxotriaJAZlsYF/RbES//r3PHEBvcYO5 cCWS5M6ur/Rad/WmTagdBsq+kcNssw== =TP+y -END PGP SIGNATURE- -- You received this message because you are subscribed to the Google Groups "qubes-devel" group. To unsubscribe from this group and stop receiving emails from it, send an email to qubes-devel+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/qubes-devel/Zdc39RJKcJbBHuf3%40mail-itl.
Re: [qubes-devel] Admin privileges of a GuiVM
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 On Mon, Feb 19, 2024 at 10:47:45PM +0100, PeakUnshift wrote: > Hello, > > When using a GuiVM, several issues appear regarding permission errors. I > created a topic on the forum and opened an issue: > - > https://forum.qubes-os.org/t/grant-full-admin-privileges-to-sys-gui-sys-gui-gpu/24368 > - https://github.com/QubesOS/qubes-issues/issues/8934 > > My message here is more general about what privileges a GuiVM should have. > Currently: > - dom0 is not accessible from sys-gui, but we can CTRL+ALT+F2 to access tty > or login back to XFCE's dom0 session. > - there is no way to access dom0 from sys-gui-gpu because the GPU is not > attached to it. > > Then, we need a way to get full admin privileges from the GuiVM: > - Should we grant full admin privileges to the GuiVM? > - Should we grand full admin privileges to a dedicated AdminVM? > - Should we create multiple adminVMs for different tasks, but all together, > give full privileges? > - Is it just a question of policies or is there other development needed in > order to execute dom0 commands from a domU? > > I'm aware that the GuiVM is still highly experimental, I try to gather > information in order to clarify the correct path to follow and thus help > future contributions. Generally, the goal is to have specific qrexec services for everything that needs dom0 action, and then grant access to those, based on some sensible policy (in default GuiVM case, user controlling GuiVM is fully in control, but there can be a case where there is separate management VM for some tasks). It shouldn't be necessary to access dom0 shell at all. In the current implementation, several of those services are missing. We collect them in this project: https://github.com/orgs/QubesOS/projects/15/views/1 So, any missing part should get a ticket that we can add to the project above. In the meantime, some access to dom0 shell is likely useful - for sys-gui you found it already, but for sys-gui-gpu probably the easiest way is to setup something like qubes.VMShell. But remember it gives sys-gui-gpu unlimited access to dom0 - be careful what you install in the template for that qube and in the qube itself. - -- Best Regards, Marek Marczykowski-Górecki Invisible Things Lab -BEGIN PGP SIGNATURE- iQEzBAEBCAAdFiEEhrpukzGPukRmQqkK24/THMrX1ywFAmXWvoEACgkQ24/THMrX 1yzQJQgAhGLTcIqVZHyNgSFk/J4QmqbIQFhqOobMYiLuEnTbwXKRawtja8mMzZux fmAwpgGv7BQxGgCJaAsB1vx7oDlz8Vl3yYKLtJapeSfXrMSHrJEKx0Nmudq3YRD1 QN4VMUkVibVbbUwjbZrwaN+t8S2zCFYkxgky4u9n3a2x18NmD2yO7vOsaSFZVb/p 02kEN/8RQJfbsc2BCp+BiK5LNVIFrjZMZ2Gb/ASJAbiVkMEK/KrtEB5BnritQ+hM GkuUAiKod/CuJKu09nSmmeMXZN2jANVr9WMic/JR1AlMkOUNLvN6wggD5Iadd1Pm f+IF2ggy7tb2oVbTzlE/nq5BTxQ7mQ== =oX8Z -END PGP SIGNATURE- -- You received this message because you are subscribed to the Google Groups "qubes-devel" group. To unsubscribe from this group and stop receiving emails from it, send an email to qubes-devel+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/qubes-devel/Zda-gQMVJG9S69nY%40mail-itl.
[qubes-devel] [qubes-announce] QSB-100: Incorrect handling of PCI devices with phantom functions (XSA-449)
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 Dear Qubes Community, We have published [Qubes Security Bulletin 100: Incorrect handling of PCI devices with phantom functions (XSA-449)](https://github.com/QubesOS/qubes-secpack/blob/main/QSBs/qsb-100-2024.txt). The text of this QSB and its accompanying cryptographic signatures are reproduced below. For an explanation of this announcement and instructions for authenticating this QSB, please see the end of this announcement. ## Qubes Security Bulletin 100 ``` ---===[ Qubes Security Bulletin 100 ]===--- 2024-01-30 Incorrect handling of PCI devices with phantom functions (XSA-449) User action - Continue to update normally [1] in order to receive the security updates described in the "Patching" section below. No other user action is required in response to this QSB. Summary - On 2024-01-30, the Xen Project published XSA-449, "pci: phantom functions assigned to incorrect contexts" [3]: | PCI devices can make use of a functionality called phantom functions, | that when enabled allows the device to generate requests using the IDs | of functions that are otherwise unpopulated. This allows a device to | extend the number of outstanding requests. | | Such phantom functions need an IOMMU context setup, but failure to | setup the context is not fatal when the device is assigned. Not | failing device assignment when such failure happens can lead to the | primary device being assigned to a guest, while some of the phantom | functions are assigned to a different domain. Impact - --- The impact as described by the Xen Project: | Under certain circumstances a malicious guest assigned a PCI device | with phantom functions may be able to access memory from a previous | owner of the device. In Qubes OS this means a PCI device that should be assigned to some qube (like sys-net or sys-usb) may retain access to dom0 memory. When that happens, the qube to which that device is assigned can compromise the whole system. But, a malicious qube cannot itself cause this condition, as it happens before it is running. For such attack to be feasible, it needs to be combined with some other method to cause PCI device assignment to fail. Affected systems - - All Qubes OS versions are affected. Only systems on which at lest one passed-through PCI device has phantom functions are affected. Patching - - The following packages contain security updates that address the vulnerabilities described in this bulletin: For Qubes 4.1, in dom0: - Xen packages, version 4.14.6-6 For Qubes 4.2, in dom0: - Xen packages, version 4.17.3-2 These packages will migrate from the security-testing repository to the current (stable) repository over the next two weeks after being tested by the community. [2] Once available, the packages are to be installed via the Qubes Update tool or its command-line equivalents. [1] Dom0 must be restarted afterward in order for the updates to take effect. If you use Anti Evil Maid, you will need to reseal your secret passphrase to new PCR values, as PCR18+19 will change due to the new Xen binaries. Credits - See the original Xen Security Advisory. References - --- [1] https://www.qubes-os.org/doc/how-to-update/ [2] https://www.qubes-os.org/doc/testing/ [3] https://xenbits.xen.org/xsa/advisory-449.html - -- The Qubes Security Team https://www.qubes-os.org/security/ ``` **Source:** <https://github.com/QubesOS/qubes-secpack/blob/main/QSBs/qsb-100-2024.txt> ## [Marek Marczykowski-Górecki](https://www.qubes-os.org/team/#marek-marczykowski-górecki)'s PGP signature ``` - -BEGIN PGP SIGNATURE- iQIzBAABCAAdFiEELRdx/k12ftx2sIn61lWk8hgw4GoFAmW5Di0ACgkQ1lWk8hgw 4GphzQ//Ta+g8Y7Cjmx0w+byISlTHoxao0yhUcwHj11ssJfjVqf1P4TNTUuzQEae 0byIay9e2jo7y8nYKsvQ5gn7aSWHBtdw/ylwghMSuQ2iXRVKgI20Iuei1pA4H9Ct +Dz5faFtZq78JZIwT2P4BRNTeuLvlU7IsmH8F4uHz/yJFqb7Ji0iSrOJ3r7/SLAI zqHKDVGhzasVZOLgi91PcGHkvK33K8YIWCSzqWO7x6sw7+FX+9IgXciQ8gbGJcmc eazNizU5H5NQNTMBghSswXKHMgi9ldNhfN8UL5Mnxz8RgN0xGRVmN01tOftJFvig sBEfADIFtToEl8rh9n4AaQR+msK87sS1VYiC6k24FzzKizaFIW08jiQv9rzZST6u YxMUXd2q64mcGzRY2QdYx/Z+07Cp3h2crLCeJXclMuD2jawBL/br/nVfdHQfqf8R 8WZUOCrlV6ekuE1L+PgSkQpOozAg4j2EDQSPYoOcrnfSuGyI08AdDl+11B4Wj1Vb WsIOY8w+469DPt+Y2NdGH3thbtPlbJcwflRdTqq0SJ4d8IRtscOYTHsiE0+xPMgu QGAZaK7YJg1c1rB40/dbLirG1j9+WR+JVLLVASi8S012qYZ5zeal7ZT6rG+gr8mK H4Ninf3Tfhq4zA8bfjmxp10uI3VsYNOH3Tgv2MgmOcxsqdK6ZoA= =/jv7 - -END PGP SIGNATURE- ``` **Source:** <https://github.com/QubesOS/qubes-secpack/blob/main/QSBs/qsb-100-2024.txt.sig.marmarek> ## [Simon Gaiser (aka HW42)](https://www.qubes-os.org/team/#simon-gaiser-aka-hw42)'s PGP signature ``` - -BEGIN PGP SIGNATURE- iQIzBAABCgAdFiEE6hjn8EDEHdrv6aoPSsGN4REuFJAFAmW5Db4ACgkQSsGN4REu FJC+mg/+Kvsi4u0Xoem+j7DW+D2FDbFZfD/6k7vacUmOVZ27gKGZiVODdBc/+dUN 2fgxRme7RPMyxABSKs9SVxpIhUoIcypc
Re: [qubes-devel] Is qrexec-policy-graph complete?
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256
On Tue, Oct 24, 2023 at 10:13:55AM +, Ben Grande wrote:
> There is no documentation on how to use it and it doesn't seem to accept
> any label/service that is not provided by default:
>
> Target can't be "@default":
This is intentional, because "@default" isn't real target - whatever it
gets resolved into is. I'll add explicit message about that.
qrexec-policy-graph should answer the question "where given call could
possibly be allowed" (and with --include-ask also including where it
with user prompt).
> ```
> $ qrexec-policy-graph --include-ask --source dev --target @default
> WARNING:root:warning: !compat-4.0 directive in file
> /etc/qubes/policy.d/35-compat.policy line 16 is transitional and will be
> deprecated
> digraph g {
> }
> ```
>
> There are more services allowed, such as "qusal.GitInit" to "@default"
> targetting "sys-git" but it doesn't show:
But this is a bug.
> ```
> $ qrexec-policy-graph --include-ask --source dev --target sys-git
> WARNING:root:warning: !compat-4.0 directive in file
> /etc/qubes/policy.d/35-compat.policy line 16 is transitional and will be
> deprecated
> digraph g {
> "dev" -> "sys-git" [label="qubes.OpenInVM" color=orange];
> "dev" -> "sys-git" [label="qubes.StartApp" color=orange];
> "dev" -> "sys-git" [label="qubes.ClipboardPaste" color=orange];
> "dev" -> "sys-git" [label="qubes.OpenURL" color=orange];
> "dev" -> "sys-git" [label="qubes.GetImageRGBA" color=orange];
> "dev" -> "sys-git" [label="qubes.Filecopy" color=orange];
> }
> ```
>
> It doesn't show any rule allowing "qusal.GitInit", but it does exist:
> ```
> $ qrexec-policy-graph --include-ask --source dev --service qusal.GitInit
> WARNING:root:warning: !compat-4.0 directive in file
> /etc/qubes/policy.d/35-compat.policy line 16 is transitional and will be
> deprecated
> digraph g {
> }
> ```
That I guess is the same as the above.
- --
Best Regards,
Marek Marczykowski-Górecki
Invisible Things Lab
-BEGIN PGP SIGNATURE-
iQEzBAEBCAAdFiEEhrpukzGPukRmQqkK24/THMrX1ywFAmU3yisACgkQ24/THMrX
1ywWCgf+OVQxFxfhUrqlCj57sLoap3KJynjKMM43uPsnNvFTV+IbVXGJr6etPhDl
Q/xw1swikyE2WdHThHKHKnQfeX/yB3sIs7fw57cDNnVeoyOMfdVVpgTVeLvXwHbO
mIz7RXaKCQG6gpkudEoCXrjggq7ffwzUj9R+njHgjspJtGSPIVJwuEB2xI07WgYk
J4BHGgA+lmHJTOzVFZy37Y7GurBbfNPpJlc0R73jwGH06b1t4UXYZ1s2dNIR8g/u
jdV+5i9vFUkSMueYysrhjnjskMIro0uOwgLfOLHXq9vAA86dJnEvldci6TCo1z9j
PhJFE8D7eTvl+KWOVjl1wAdjWXIGEg==
=GP/r
-END PGP SIGNATURE-
--
You received this message because you are subscribed to the Google Groups
"qubes-devel" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to qubes-devel+unsubscr...@googlegroups.com.
To view this discussion on the web visit
https://groups.google.com/d/msgid/qubes-devel/ZTfKK2LhzR0RXtsG%40mail-itl.
Re: [qubes-devel] How to make dom0 qrexec call resolve @default token
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 On Tue, Oct 24, 2023 at 09:54:21AM +, Ben Grande wrote: > On 23-10-24 00:36:26, Marek Marczykowski-Górecki wrote: > > On Mon, Oct 23, 2023 at 09:24:13PM +, Ben Grande wrote: > > > Hello. > > > > > > Dom0 is not normally a client for extraneous qrexec calls, but in this > > > case, I need dom0 to resolve the domain name from the token @default via > > > policy. > > > > > > Policy: > > > > > > service * dom0 @default allow target=mydomain > > > > > > Call: > > > > > > qrexec-client -d @default -- 'DEFAULT:QUBESRPC service dom0' > > > > > > Dom0 does not requires the policy the call to be allowed, as it is always > > > allowed. Watching the qrexec policy logs, the call from Dom0 is not > > > logged. > > > > > > If I run from dom0: > > > > > > qrexec-policy 0 dom0 @default service 1 > > > > > > It resolves the domain but fails to run the command: > > > > > > INFO:policy:qrexec: service: dom0 -> @default: allowed to sys-git > > > 2023-10-23 21:19:28.154 qrexec-client[32893]: > > > qrexec-client.c:184:connect_unix_socket: connect: No such file or > > > directory > > > ERROR:policy:qrexec: service: dom0 -> @default: error while executing: > > > qrexec-client failed: ['/usr/lib/qubes/qrexec-client', '-d', 'mydomain', > > > '-c', '1,dom0,0', '-E', '--', 'DEFAULT:QUBESRPC service dom0'] > > > > > > If I run the command directly without the request id and the literal > > > domain name, it works: > > > > > > qrexec-client -d mydomain -- 'DEFAULT:QUBESRPC service dom0' > > > > > > How can I force dom0 to use the '@default' token? > > > As 'qrexec-client' does not allow tokens in the domain name yet, would > > > this be interesting to have? > > > > > > Documents read: > > > - https://www.qubes-os.org/doc/qrexec-internals/ > > > - https://www.qubes-os.org/doc/qrexec-internals/ > > > > > > I don't think there is one-step solution, but you can get policy > > resolved by using `qrexec-policy` in the 3-arg form (skipping domain id > > and process ident). Then, you'll get the result in key=value format, > > including resolved target= that you can use in a qvm-run (or > > qrexec-client) call. It even works with `ask` policy (you get the > > prompt), which means we finally can implement qvm-copy (not just > > qvm-copy-to-vm) in dom0 too :) > > > > -- > > Best Regards, > > Marek Marczykowski-Górecki > > Invisible Things Lab > > I'm on R4.1. Up-to-date. > > Can you please give an example of a working 3-arg form as it seems that > all positional arguments are required? Ah, right, 3-arg form is a R4.2 thing. This: [user@dom0 ~]$ qrexec-policy --help usage: qrexec-policy-exec -h usage: qrexec-policy-exec [--assume-yes-for-ask] [--just-evaluate] [--path PATH] SOURCE TARGET service+argument usage: qrexec-policy-exec [--assume-yes-for-ask] [--just-evaluate] [--path PATH] domain-id SOURCE TARGET service+argument process-ident To evaluate policy, pass 3 positional arguments: - Source domain name - Target domain name - Service name and argument separated by "+" To actually run a qrexec call, pass 5 positional arguments: - Source domain ID (Xen or similar, not Qubes ID) - Source domain name - Target domain name - Service name and argument separated by "+" - Qrexec process identifier (for data channel connection) Note that this usage is deprecated. positional arguments: args options: -h, --helpshow this help message and exit --assume-yes-for-ask Allow run of service without confirmation if policy say 'ask' --just-evaluate Do not run the service, only evaluate policy; retcode=0 means 'allow' --path PATH Use alternative policy path > Policy: > ``` > ## Do not modify this file, create a new policy with with a lower number in > the > ## file name instead. For example `30-user.policy`. > qusal.GitFetch * dom0 @default allow target=sys-git > qusal.GitPush * dom0 @default allow target=sys-git > qusal.GitInit * dom0 @default allow target=sys-git > qusal.GitFetch * @adminvm @default allow target=sys-git > qusal.GitPush * @adminvm @default allow target=sys-git > qusal.GitInit * @adminvm @default allow target=sys-git > > qusal.GitFetch * @anyvm @default ask target=sys-git default_target=sys-git > qusal.GitPush * @anyvm @default ask target=sys-g
Re: [qubes-devel] How to make dom0 qrexec call resolve @default token
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 On Mon, Oct 23, 2023 at 09:24:13PM +, Ben Grande wrote: > Hello. > > Dom0 is not normally a client for extraneous qrexec calls, but in this > case, I need dom0 to resolve the domain name from the token @default via > policy. > > Policy: > > service * dom0 @default allow target=mydomain > > Call: > > qrexec-client -d @default -- 'DEFAULT:QUBESRPC service dom0' > > Dom0 does not requires the policy the call to be allowed, as it is always > allowed. Watching the qrexec policy logs, the call from Dom0 is not > logged. > > If I run from dom0: > > qrexec-policy 0 dom0 @default service 1 > > It resolves the domain but fails to run the command: > > INFO:policy:qrexec: service: dom0 -> @default: allowed to sys-git > 2023-10-23 21:19:28.154 qrexec-client[32893]: > qrexec-client.c:184:connect_unix_socket: connect: No such file or directory > ERROR:policy:qrexec: service: dom0 -> @default: error while executing: > qrexec-client failed: ['/usr/lib/qubes/qrexec-client', '-d', 'mydomain', > '-c', '1,dom0,0', '-E', '--', 'DEFAULT:QUBESRPC service dom0'] > > If I run the command directly without the request id and the literal domain > name, it works: > > qrexec-client -d mydomain -- 'DEFAULT:QUBESRPC service dom0' > > How can I force dom0 to use the '@default' token? > As 'qrexec-client' does not allow tokens in the domain name yet, would > this be interesting to have? > > Documents read: > - https://www.qubes-os.org/doc/qrexec-internals/ > - https://www.qubes-os.org/doc/qrexec-internals/ I don't think there is one-step solution, but you can get policy resolved by using `qrexec-policy` in the 3-arg form (skipping domain id and process ident). Then, you'll get the result in key=value format, including resolved target= that you can use in a qvm-run (or qrexec-client) call. It even works with `ask` policy (you get the prompt), which means we finally can implement qvm-copy (not just qvm-copy-to-vm) in dom0 too :) - -- Best Regards, Marek Marczykowski-Górecki Invisible Things Lab -BEGIN PGP SIGNATURE- iQEzBAEBCAAdFiEEhrpukzGPukRmQqkK24/THMrX1ywFAmU29WoACgkQ24/THMrX 1ywsSAgAiLVRdMfihuve31orGwwKzLr158cfHVqVgiB93I4KulRJZJp5nWCMHn9N RzfcLGE8fVbIXMdgSS2zkrRnerNQaJMMHsXr7T+zj1KRkyV3BFKAn0LuALITkV8z W4ovnk2xtfuP2aDY13VoLCYllE8xPwbUBOUPLFQSMJiBLQVh0OfYNsbnyzITZ0W8 bbC20IGjMmvwj+HH91OyfhEphRZlDf8BpxCb1shpN7tdyBOelBiD4HyFP7BhJUZv 9lovughJRah6i0CDUfVI+eFVpsYM5owHCsa+OnUY5How4mu2H5rBYbEjbhxcY0gl 1E5RvgCuqCZp1W9o81mdJEGW7J2udQ== =QTs9 -END PGP SIGNATURE- -- You received this message because you are subscribed to the Google Groups "qubes-devel" group. To unsubscribe from this group and stop receiving emails from it, send an email to qubes-devel+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/qubes-devel/ZTb1al5e6YHBtRR0%40mail-itl.
Re: [qubes-devel] Re: qubes-policy-lint and qubes-policy-editor-terminal
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 On Sat, Aug 26, 2023 at 06:40:32PM +0200, Marek Marczykowski-Górecki wrote: > On Fri, Aug 25, 2023 at 04:52:52PM +0200, Marek Marczykowski-Górecki wrote: > > On Mon, Aug 21, 2023 at 08:49:21PM +, Ben Grande wrote: > > > On 23-08-20 14:01:53, Marek Marczykowski-Górecki wrote: > > > > On Fri, Aug 11, 2023 at 02:17:00PM +, Ben Grande wrote: > > > > > Status: > > > > > - Missing change 'qubes-policy-editor' to 'qubes-policy-editor-gui'; > > > > > > > > https://github.com/QubesOS/qubes-desktop-linux-manager/pull/172 > > > > > > > > You can rename to plain qubes-policy-editor now. > > > > > > > > While at it, please add new files to packaging > > > > (debian/qubes-core-qrexec.install, rpm_spec/qubes-qrexec.spec.in). Right > > > > now packages fail to build. > > > > > > > > > - Missing review of the last commit quoted above. > > > > > > > > The last commit looks fine. > > > > > > Added files to packaging. > > > > You missed files in python lib dir (qrexec/tools/qubes_policy_...) in > > the spec file. > > I see you added it, but as qrexec_policy_* instead of qubes_policy_*... And also pylint complains... See: https://gitlab.com/QubesOS/qubes-core-qrexec/-/pipelines/982836773 > > Generally, the preferred workflow is through github pull requests - we > > have CI configured there to catch issues like this. If you really hate > > github, sending patches like this is okay too, but since it requires a > > bit more manual work on my side (including pushing them to CI > > manually...), it also takes some more time to get them merged. > > > > > I believe in this case it is easier for you to pull from the 'lint' > > > branch instead of applying the patches manually as multiple commits were > > > done. If that is not the case, I will post the patches. > > > > > > https://codeberg.org/ben.grande.b/qubes-core-qrexec/src/branch/lint > > > > Yes, that's fine (but see above). - -- Best Regards, Marek Marczykowski-Górecki Invisible Things Lab -BEGIN PGP SIGNATURE- iQEzBAEBCAAdFiEEhrpukzGPukRmQqkK24/THMrX1ywFAmTqK34ACgkQ24/THMrX 1yxtPwf/Z52Kt409yhkedY7gkhdHR7xH11IHLMGPYlBTc/RWhcExNgP5PMDtSW/K Ab2P1MMZq3z4KbdkyDNjwNvuG70fQtlMLuyGi/2ITUiTFimQUUtE/1FUJD07X1+8 CPUUr0J27YiqkDs/zNCWH+TXFzj+tMi3AMEAdt3uEH9UbbS9d133CW9ao6deKxU9 TvTJPXgPrxaDPMHzmNGLwZZEy6SeRJ3tFW96WKU7eySN+5Qz4vlfcvjReT8BYgmS /ZzTkTTFZs+jRcQIemnUyCqTB9S2G0skrCXtPVmx/NLJ70r22d1Rwaxq+dN86lCI BnlgW66GfBZBBvfWeQl6eMimKES/wg== =YRF9 -END PGP SIGNATURE- -- You received this message because you are subscribed to the Google Groups "qubes-devel" group. To unsubscribe from this group and stop receiving emails from it, send an email to qubes-devel+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/qubes-devel/ZOorforYf%2Bq4I4e8%40mail-itl.
Re: [qubes-devel] Re: qubes-policy-lint and qubes-policy-editor-terminal
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 On Fri, Aug 25, 2023 at 04:52:52PM +0200, Marek Marczykowski-Górecki wrote: > On Mon, Aug 21, 2023 at 08:49:21PM +, Ben Grande wrote: > > On 23-08-20 14:01:53, Marek Marczykowski-Górecki wrote: > > > On Fri, Aug 11, 2023 at 02:17:00PM +, Ben Grande wrote: > > > > Status: > > > > - Missing change 'qubes-policy-editor' to 'qubes-policy-editor-gui'; > > > > > > https://github.com/QubesOS/qubes-desktop-linux-manager/pull/172 > > > > > > You can rename to plain qubes-policy-editor now. > > > > > > While at it, please add new files to packaging > > > (debian/qubes-core-qrexec.install, rpm_spec/qubes-qrexec.spec.in). Right > > > now packages fail to build. > > > > > > > - Missing review of the last commit quoted above. > > > > > > The last commit looks fine. > > > > Added files to packaging. > > You missed files in python lib dir (qrexec/tools/qubes_policy_...) in > the spec file. I see you added it, but as qrexec_policy_* instead of qubes_policy_*... > Generally, the preferred workflow is through github pull requests - we > have CI configured there to catch issues like this. If you really hate > github, sending patches like this is okay too, but since it requires a > bit more manual work on my side (including pushing them to CI > manually...), it also takes some more time to get them merged. > > > I believe in this case it is easier for you to pull from the 'lint' > > branch instead of applying the patches manually as multiple commits were > > done. If that is not the case, I will post the patches. > > > > https://codeberg.org/ben.grande.b/qubes-core-qrexec/src/branch/lint > > Yes, that's fine (but see above). - -- Best Regards, Marek Marczykowski-Górecki Invisible Things Lab -BEGIN PGP SIGNATURE- iQEzBAEBCAAdFiEEhrpukzGPukRmQqkK24/THMrX1ywFAmTqKwAACgkQ24/THMrX 1yxnoAf/RLmMwlq+Fr66zwiwfo35U5twb6v+IQ5f5rtNGj1AR4b+iRB96qTTOMRc 3gfUBCHp9m54aVXnO0xIHoTaLnVSgYR99WOTLOZYiGEBN66/gWdWvehpTbuTeXO7 aZ/9vnRJc0rX8vwcvUS76XZzUJezP1r49d2V/7dZW/uheVW38FWOGqkwekEwgz85 HT+I7JLPcytz76RU9Jxo8o8oWMv08f/BnJjPqP2kfq5NXZcdM8zsj8ZNdTNGwmNt IWsY97NmWx3hH8mGEMtYWqBK/losDX2nEZE5lyGkU0cPdH4nr88QiyxVb7Z2Yqx+ hMB1G4GD337IItPPA4PLZIqK7HhmXQ== =PvDd -END PGP SIGNATURE- -- You received this message because you are subscribed to the Google Groups "qubes-devel" group. To unsubscribe from this group and stop receiving emails from it, send an email to qubes-devel+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/qubes-devel/ZOorAEx3mpv02z67%40mail-itl.
Re: [qubes-devel] Re: qubes-policy-lint and qubes-policy-editor-terminal
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 On Mon, Aug 21, 2023 at 08:49:21PM +, Ben Grande wrote: > On 23-08-20 14:01:53, Marek Marczykowski-Górecki wrote: > > On Fri, Aug 11, 2023 at 02:17:00PM +, Ben Grande wrote: > > > Status: > > > - Missing change 'qubes-policy-editor' to 'qubes-policy-editor-gui'; > > > > https://github.com/QubesOS/qubes-desktop-linux-manager/pull/172 > > > > You can rename to plain qubes-policy-editor now. > > > > While at it, please add new files to packaging > > (debian/qubes-core-qrexec.install, rpm_spec/qubes-qrexec.spec.in). Right > > now packages fail to build. > > > > > - Missing review of the last commit quoted above. > > > > The last commit looks fine. > > Added files to packaging. You missed files in python lib dir (qrexec/tools/qubes_policy_...) in the spec file. Generally, the preferred workflow is through github pull requests - we have CI configured there to catch issues like this. If you really hate github, sending patches like this is okay too, but since it requires a bit more manual work on my side (including pushing them to CI manually...), it also takes some more time to get them merged. > I believe in this case it is easier for you to pull from the 'lint' > branch instead of applying the patches manually as multiple commits were > done. If that is not the case, I will post the patches. > > https://codeberg.org/ben.grande.b/qubes-core-qrexec/src/branch/lint Yes, that's fine (but see above). - -- Best Regards, Marek Marczykowski-Górecki Invisible Things Lab -BEGIN PGP SIGNATURE- iQEyBAEBCAAdFiEEhrpukzGPukRmQqkK24/THMrX1ywFAmTowEAACgkQ24/THMrX 1yyQowf47CY7VTxIizI1fk8v5c58RIltQ9YFF7eRbhB87TaiH3GEhbQQfoWmv41k 4rvbWWP9QuN7tVoTCAfadB10BH0cI5H5AmdvhFzF1iMwlaEv7726pnX6k+qbhAM0 Nlvh9KbfczjxPspjq80ETc38pHX2lO6x6G7jlYubNl7E96mPhJwCxK5QD0EETvMo lfyIXIGX0uMHBry+SinhAY4WGGWoTKB+BA6/iJrfiooCJHKcJNVkI3HjpmnvpM3l 35ZRzBLCYYqQi4CqSkPwDhXGgWkTxdp/b0JzVyeyvcjkhAVXcD8ba9t0JRm68QAd T+69fv45P9OHvu5ZtywYEhPssSFP =5ea7 -END PGP SIGNATURE- -- You received this message because you are subscribed to the Google Groups "qubes-devel" group. To unsubscribe from this group and stop receiving emails from it, send an email to qubes-devel+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/qubes-devel/ZOjAQDbDKSxAuAjs%40mail-itl.
Re: [qubes-devel] Re: qubes-policy-lint and qubes-policy-editor-terminal
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 On Fri, Aug 11, 2023 at 02:17:00PM +, Ben Grande wrote: > On 23-06-01 19:03:31, Ben Grande wrote: > > The editor does not require the policy(.include).List RPC as of the last > > commit[0], only requiring policy(.include).Get and > > policy(.include).Replace. > > > > The downside is that when the file is not found, it guesses the file > > path using POLICYPATH and INCLUDEPATH, when running from and AdminVM, > > the qubes-core-qrexec package needs to be the same on Dom0 and AdminVM. > > > > Can this cause problems? Should it be reverted? I matching the > > 'wanted_path' via regex a better alternative? > > > > https://codeberg.org/ben.grande.b/qubes-core-qrexec/commit/445e7db143b5894a8c75394bd2a0bd5a7a8b759e > > > > -- > > Benjamin Grande > > Reminding of code contribution. Sorry for late review. > Status: > - Missing change 'qubes-policy-editor' to 'qubes-policy-editor-gui'; https://github.com/QubesOS/qubes-desktop-linux-manager/pull/172 You can rename to plain qubes-policy-editor now. While at it, please add new files to packaging (debian/qubes-core-qrexec.install, rpm_spec/qubes-qrexec.spec.in). Right now packages fail to build. > - Missing review of the last commit quoted above. The last commit looks fine. - -- Best Regards, Marek Marczykowski-Górecki Invisible Things Lab -BEGIN PGP SIGNATURE- iQEzBAEBCAAdFiEEhrpukzGPukRmQqkK24/THMrX1ywFAmTiALEACgkQ24/THMrX 1yyDEAgAiBOCrsIrQ3+AbSY86BDVRpUs+SI7flX+h/9oCcVR/p1bLhzlleBawIGW nDhHwYs8kfShPUFoYB6ZNo8UCW+IOy5aWs+MJ8JMmC9CpekBhMMbR5Hambs4RX93 jUmahuK3AqQgj1NDOjRxxdx2/uurHLb/ij/ftiRNgtL9wwIQMLZlRa3xnfBmDISK 2CDfGu3xgYZ2AZYw8uCeHuUDXQfnCyHulvDmgLP3nAT+3vi2i+LxmDsip8YOgq6b KE2qQ1BwYH8skH03r6iswqbv0A1DoH6KNi9YrzXywjtfmczqvsSP6tME7hksgxnd Fad1DOxZwn8uhIRowIsTROtPx5EhTw== =P2rL -END PGP SIGNATURE- -- You received this message because you are subscribed to the Google Groups "qubes-devel" group. To unsubscribe from this group and stop receiving emails from it, send an email to qubes-devel+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/qubes-devel/ZOIAsQhJpDN%2B28Am%40mail-itl.
Re: [qubes-devel] Re: [PATCH] parser: Change warning of invalid path to error
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256
On Fri, Aug 11, 2023 at 02:13:56PM +, Ben Grande wrote:
> On 23-05-26 16:59:07, Ben Grande wrote:
> > Signed-off-by: Ben Grande
> > ---
> > qrexec/policy/parser.py | 11 +--
> > 1 file changed, 5 insertions(+), 6 deletions(-)
> >
> > diff --git a/qrexec/policy/parser.py b/qrexec/policy/parser.py
> > index ab50f9e..143f77f 100644
> > --- a/qrexec/policy/parser.py
> > +++ b/qrexec/policy/parser.py
> > @@ -1956,15 +1956,14 @@ class ToposortMixIn:
> > if "/" in key and (
> > not key.startswith("include/") or key.count("/") > 1
> > ):
> > -# TODO make this an error, since we shouldn't accept this
> > anyway
> > -logging.warning(
> > -"ignoring path %r included in %s on line %d; "
> > -"expect problems with import order",
> > -included_path,
> > +raise PolicySyntaxError(
> > filepath,
> > lineno,
> > +"invalid path {}, only paths inside the directories {} and
> > "
> > +"{}/include are considered".format(
> > +included_path, POLICYPATH, POLICYPATH
> > +),
> > )
> > -return
> >
> > self.included_paths[key].add(included_path)
> >
> > --
> > Benjamin Grande
>
> Reminding of unreviewed patch.
Pylint complained about duplicated POLICYPATH, so I adjusted it to use
named arguments. Otherwise, applied, thanks!
- --
Best Regards,
Marek Marczykowski-Górecki
Invisible Things Lab
-BEGIN PGP SIGNATURE-
iQEzBAEBCAAdFiEEhrpukzGPukRmQqkK24/THMrX1ywFAmTh//8ACgkQ24/THMrX
1yz4PQf+JidHMMTgRgpSF6hzNoQG6J9QUxmKsdAil1ZpbGlwkS7OCRxAupBsDkwc
5rYX52bPzq4UWnK1Bq8urHB0EyxaAt8y2XVtMbaTS4UMpHTEzRj34g0jrsRUkRHl
tmpAQsDbloqRA6N6IzyYOo7J8E8LldyyiueesuFBi7H/fGJZq74MQ9M1nZdC/ibn
mgHT4OsbuI2i1xapZ6sxxUFsywJHf9ojUFq7Yn+MJFcFhrB0wZ+x2fdRg5XdoJuP
UJOlRGytrznDTxvvCVermyAOo/RHAF2tIUQPkHKEak5wgywbYzPv/QTO0voO/784
ZVdvuAbJ4cjYPAfzkae2q1KZDY0hXw==
=6ED7
-END PGP SIGNATURE-
--
You received this message because you are subscribed to the Google Groups
"qubes-devel" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to qubes-devel+unsubscr...@googlegroups.com.
To view this discussion on the web visit
https://groups.google.com/d/msgid/qubes-devel/ZOH//g2z3Sl5tZwV%40mail-itl.
Re: [qubes-devel] Re: [PATCH v3] Fix policy.Replace changing mode and owners
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256
On Fri, Aug 11, 2023 at 02:12:25PM +, Ben Grande wrote:
> On 23-05-28 22:35:31, Ben Grande wrote:
> > Enforce file mode and ownership for replaced files.
> >
> > Signed-off-by: Ben Grande
> > ---
> > qrexec/policy/admin.py | 9 +
> > 1 file changed, 9 insertions(+)
> >
> > diff --git a/qrexec/policy/admin.py b/qrexec/policy/admin.py
> > index da5bd9f..d575a6e 100644
> > --- a/qrexec/policy/admin.py
> > +++ b/qrexec/policy/admin.py
> > @@ -19,6 +19,8 @@
> >
> > from typing import Optional
> > from pathlib import Path
> > +from pwd import getpwnam
> > +from grp import getgrnam
> > import contextlib
> > import fcntl
> > import os
> > @@ -201,6 +203,13 @@ class PolicyAdmin:
> >
> > temp_path = path.with_name(RENAME_PREFIX + path.name)
> > temp_path.write_bytes(data)
> > +temp_path.chmod(0o664)
> > +uid = getpwnam("root").pw_uid
> > +gid = getgrnam("qubes").gr_gid
> > +try:
> > +os.chown(temp_path, uid, gid)
> > +except PermissionError:
> > +pass
> > temp_path.rename(path)
> >
> > # Remove
> > --
> > Benjamin Grande
> >
>
> Reminding of unreviewed patch.
Thanks, applied.
I also changed it to handle missing 'qubes' group, because that doesn't
exist in CI.
- --
Best Regards,
Marek Marczykowski-Górecki
Invisible Things Lab
-BEGIN PGP SIGNATURE-
iQEzBAEBCAAdFiEEhrpukzGPukRmQqkK24/THMrX1ywFAmTh/+oACgkQ24/THMrX
1yzYIQf/Tg2vIz3J6CvqEd3mfqrf5KfEI3l+bC/NQOJxcg+09anC+VeTN/gA1hVw
kmmTBHdfTXJCq6f4KOMHRfNMPRdtarFCdz6UOIfqkHfWlmY8LAokRc/+BqCiJxgQ
/lR2y2Pv2/zNHys67p6k4ZN1Xqxp/dI0NjsnJH55NTeME4EFVPu8d3ZW7OPHqKfm
Ex8m9QYzzIJmrxDTgjKmogv7mMiEz1T0awjzwwDJrnprgnfKvT3LuIj6WIm0e8QO
VC9a4o6sCoxTMWLIasmvQTjWT45Vpi04F0MFlRGJJAa0MumccLkFm7qQvOouP2bu
R60o4/tlfE/qwvYed8JXbdwGf3rZew==
=zZwV
-END PGP SIGNATURE-
--
You received this message because you are subscribed to the Google Groups
"qubes-devel" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to qubes-devel+unsubscr...@googlegroups.com.
To view this discussion on the web visit
https://groups.google.com/d/msgid/qubes-devel/ZOH/6hzpBDuXBOeu%40mail-itl.
Re: [qubes-devel] Changing the way we use milestones in the issue tracker
only looked at and considered each issue in a given milestones; > > they've actually decided that action will be taken on that issue and plan > > for it to be done for that release! (Of course, the Qubes devs reserve the > > right to modify or remove milestones at any point at their discretion. > > Assigning an issue to a milestone isn't a binding commitment of any kind, > > and the realities of the software development process guarantee that > > milestone assignments will often change.) > > > > A side benefit of this new system is that it makes it clearer that every > > issue opened is merely "under consideration" until the Qubes developers > > approve of it and decide to act on it. (Even under the old system, > > assigning a bug report to the "Release 4.1. updates" milestone, for > > example, doesn't mean the Qubes developers plan to act on it or even that > > they agree that it's really a bug in 4.1.) > > > > Since we will no longer be using milestones to represent which release(s) a > > bug affects, we'll instead use labels like "affects-4.1" and "affects-4.2." > > This will allow us to accurately track cases in which a bug affects > > multiple releases. (I expect that "affects-*" labels will be used mostly > > with bug reports, but there are probably some cases in which they can > > sensibly apply to tasks and enhancements.) > > > > We currently have a milestone called "Non-release," which is for issues > > that are independent of the Qubes OS release cycle, such as website, > > documentation, and project management issues. This milestone provides > > little value and will be phased out. The main reason it existed under the > > old system is to satisfy the "every issue must be assigned to a milestone" > > rule, but it's actually redundant with labels like "C: doc." > > > > Similarly, we currently have the "Release TBD" milestone, which is for > > enhancements and tasks that will (or would) be specific to a Qubes OS > > release but have yet to be assigned to a specific release milestone. This > > milestone makes no sense under the new system, as *every* issue is in this > > state by default until it is hand-selected for inclusion in a specific > > release milestone. > > > > Finally, we have milestones like "Release 4.1 updates" (as opposed to just > > "Release 4.1"). Under the old system, these "* updates" milestones were > > used to collect issues (mostly bug reports) that were filed after the > > corresponding stable version was released (in this case, 4.1). In other > > words, all 4.1 bugs reported during the testing stages were assigned to > > "Release 4.1," then the stable 4.1 release was announced, the "Release 4.1" > > milestone was closed, and the "Release 4.1 updates" milestone was opened in > > its place. (In practice, it was already open by this point.) All "Release > > 4.1" bug reports that were still open and all subsequent 4.1 bug reports > > from that point onward were assigned to this "Release 4.1 updates" > > milestone instead. (In some cases, some bugs that the devs knew they > > wouldn't fix in time for the 4.1 release might've been assigned to "Release > > 4.1 updates" early.) Not only is this process confusing to newcomers > > (because the distinction between "Release 4.1" and "Release 4.1 updates" is > > too subtle); it also renders the progress indicator on the "Release 4.1 > > updates" milestone fairly meaningless, as it is attempting to track > > progress on updating a version that has already been released, which is a > > never-ending process until that release reaches EOL. These "* updates" > > milestones are also being phased out. > > > > Thanks for reading! To view the latest milestone guidelines at any given > > time, please see: https://www.qubes-os.org/doc/issue-tracking/#milestones > > > > -- > > You received this message because you are subscribed to the Google Groups > > "qubes-devel" group. > > To unsubscribe from this group and stop receiving emails from it, send an > > email to qubes-devel+unsubscr...@googlegroups.com. > > To view this discussion on the web visit > > https://groups.google.com/d/msgid/qubes-devel/6987bd94-817c-f216-e923-0d3029723f43%40qubes-os.org. > > > > -- > You received this message because you are subscribed to the Google Groups > "qubes-devel" group. > To unsubscribe from this group and stop receiving emails from it, send an > email to qubes-devel+unsubscr...@googlegroups.com. > To view this discussion on the web visit > https://groups.google.com/d/msgid/qubes-devel/NbPVjTN--3-9%40tutanota.com. - -- Best Regards, Marek Marczykowski-Górecki Invisible Things Lab -BEGIN PGP SIGNATURE- iQEzBAEBCAAdFiEEhrpukzGPukRmQqkK24/THMrX1ywFAmTTnwUACgkQ24/THMrX 1yzpSwf+OvC4uOCQjLKsOZyzAVPGpoDkzizF0NScXodGysRxfjnrUlK4DbLGZ/Uz lHfCZjshDP19YjTaGBMtFx0+5LZVtUsn/LufbpSTQAFZ3eInnyI3ggIuuSW5Ru1m 4n29/t147A+RmMQn2TL4z8hP7DDSyYGdxqLIE26/IvukWrfvAlBQPlMIov1FRf4D lHloo7LmNQFa19flf6yoCluRPrP1OLjQyh71+KsGnWlR1f+eZ4tLBiINrv3Sb9zd mcqBgsEkTtFtATbLYDSP7zJMkef5WrLOcZkoeMpwk2YBTwpPW+EC3wYzm635wcby hc3ZGqBAVv4CPG5HTs+8dfy03DOj0A== =gHO0 -END PGP SIGNATURE- -- You received this message because you are subscribed to the Google Groups "qubes-devel" group. To unsubscribe from this group and stop receiving emails from it, send an email to qubes-devel+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/qubes-devel/ZNOfBTfiAXP0oONo%40mail-itl.
Re: [qubes-devel] [PATCH] Fix qubes-input-sender-mouse@.service failing on boot
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 On Fri, Jun 30, 2023 at 01:41:10AM +, 8h45 via qubes-devel wrote: > If sys-usb boots up before the user has logged in, > qubes-input-sender-mouse@.service fails permanently. This patch makes the > service restart on failure at a reasonable time interval. If the policy is set to "allow", it should work even before log in. But with policy "ask", indeed it will fail. But then, there is a post-login script to restart those services one time. It's called via /etc/xdg/autostart/qubes-input-trigger.desktop in sys-usb (/etc/xdg/autostart is processed when starting user's graphical session, so - just after log-in). If for some reason it doesn't work for you, the issue is there. > diff --git a/qubes-rpc/qubes-input-sender-mouse@.service > b/qubes-rpc/qubes-input-sender-mouse@.service > index 309f60f..18fbb72 100644 > --- a/qubes-rpc/qubes-input-sender-mouse@.service > +++ b/qubes-rpc/qubes-input-sender-mouse@.service > @@ -6,3 +6,5 @@ After=qubes-qrexec-agent.service > Environment=TARGET_DOMAIN=dom0 > EnvironmentFile=-/etc/qubes/input-proxy-target > ExecStart=/usr/bin/qubes-input-sender qubes.InputMouse /dev/input/%i > "$TARGET_DOMAIN" > +Restart=always > +RestartSec=1 Restarting the failed service indefinitely, every 1s is a bad idea. The common case of a failure is (intentional) policy deny, and restarting every 1s will both waste resources and spam the user with notifications about the refusal. - -- Best Regards, Marek Marczykowski-Górecki Invisible Things Lab -BEGIN PGP SIGNATURE- iQEzBAEBCAAdFiEEhrpukzGPukRmQqkK24/THMrX1ywFAmSoHKoACgkQ24/THMrX 1yx2oggAiuA6Pfwqoavx8pgEO2W8xuZZLBi9saBTTifrGEoQgB0FeuhL+NMBZaYS wcPB2k0Ru8E/QTvZxcm7Ug+0F/s23j46Pr02iKDykIMAuKxaYleuhYjpOrvjCH5c QWgnlEiN9PfFzYFb8k9JCitwnuB5umYct6e5/NZeXQx4ooewXcQNjbUz63lbmiCk 00dK3ru0xuexl4lgYnIDwjpqNLel0SmkMlsITPIh6gOJ7/7MmkroSx2XUbpO/8a1 7JVoOkTNAV9+0JM/AVHtXtEXVT9hoqrhNEehSYK5VqNcWVNozQQX2rJT0U+XJswO vdzeEhF6PiAPLiRbYEpMUgjI3hP+hw== =20O+ -END PGP SIGNATURE- -- You received this message because you are subscribed to the Google Groups "qubes-devel" group. To unsubscribe from this group and stop receiving emails from it, send an email to qubes-devel+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/qubes-devel/ZKgcqiB/wq5aHqOq%40mail-itl.
Re: [qubes-devel] [PATCH v2] Fix policy.Replace changing mode and owners mode
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256
On Sun, May 28, 2023 at 09:41:37AM +, Ben Grande wrote:
> Enforce file mode and ownership for replaced files.
>
> Signed-off-by: Ben Grande
> ---
> qrexec/policy/admin.py | 6 ++
> 1 file changed, 6 insertions(+)
>
> diff --git a/qrexec/policy/admin.py b/qrexec/policy/admin.py
> index da5bd9f..5f80070 100644
> --- a/qrexec/policy/admin.py
> +++ b/qrexec/policy/admin.py
> @@ -19,6 +19,8 @@
>
> from typing import Optional
> from pathlib import Path
> +from pwd import getpwnam
> +from grp import getgrnam
> import contextlib
> import fcntl
> import os
> @@ -201,6 +203,10 @@ class PolicyAdmin:
>
> temp_path = path.with_name(RENAME_PREFIX + path.name)
> temp_path.write_bytes(data)
> +temp_path.chmod(0o664)
> +uid = getpwnam("root").pw_uid
> +gid = getgrnam("qubes").gr_gid
> +os.chown(temp_path, uid, gid)
Just in case, I'd wrap it in try/except to not fail the whole operation
if chown fails (if the thing is running as non-root user for example).
> temp_path.rename(path)
>
> # Remove
> --
> Benjamin Grande
>
> --
> You received this message because you are subscribed to the Google Groups
> "qubes-devel" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to qubes-devel+unsubscr...@googlegroups.com.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/qubes-devel/ZHMh0fQxcKHG70gP%40personal-mutt.
- --
Best Regards,
Marek Marczykowski-Górecki
Invisible Things Lab
-BEGIN PGP SIGNATURE-
iQEzBAEBCAAdFiEEhrpukzGPukRmQqkK24/THMrX1ywFAmRzWZEACgkQ24/THMrX
1yxnvAf+NJ5PSy0IKlHduJiMSsuGSmE1QarvNp6hOMZqxGgqjRg9pKwS2tF69StW
1zOM5xNmls888CKkxKeS7SsSOAMAlRt8gf1+mhS3SGGPYrDiZZcuvzClBw+JOmn7
moAbokIL5qBtTZ57X4eBC5e7iOisA1n1VIqCqwLxnQOsb2aP5BoItcpIKfilIh+I
5RI3rs/58fQfKVsLfb5IsLqolGh4PX3OKqDq8rCwABPmMYfyqfGAJ5ywiiV01LRf
lgsKVJHM1mQuSYUaazEmOVFLWvc73CeSbk+Blz08cYuogxnMK25iMSW78mPm5DiL
xo4w3oq4DvvjPW6wJcgOAN987AulDQ==
=utmA
-END PGP SIGNATURE-
--
You received this message because you are subscribed to the Google Groups
"qubes-devel" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to qubes-devel+unsubscr...@googlegroups.com.
To view this discussion on the web visit
https://groups.google.com/d/msgid/qubes-devel/ZHNZkbdivHwyTZG2%40mail-itl.
Re: [qubes-devel] Re: [PATCH] Fix policy.Replace changing the file mode
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 On Sat, May 27, 2023 at 07:33:53PM +, Ben Grande wrote: > On 23-05-27 19:25:54, Ben Grande wrote: > > Without this, it defaults to what unmask allows, normally 644. > > Without being group owned, editing the policy manually leads to a RO > > file and if the user force writes, will change the ownership to > > user:user. > > > > Signed-off-by: Ben Grande > > --- > > qrexec/policy/admin.py | 1 + > > 1 file changed, 1 insertion(+) > > > > diff --git a/qrexec/policy/admin.py b/qrexec/policy/admin.py > > index da5bd9f..c5bfc23 100644 > > --- a/qrexec/policy/admin.py > > +++ b/qrexec/policy/admin.py > > @@ -201,6 +201,7 @@ class PolicyAdmin: > > > > temp_path = path.with_name(RENAME_PREFIX + path.name) > > temp_path.write_bytes(data) > > +temp_path.chmod(0o664) > > temp_path.rename(path) > > > > # Remove > > -- > > Benjamin Grande > > Perhaps it should also set the ownership to root:qubes? Yes, I think so. - -- Best Regards, Marek Marczykowski-Górecki Invisible Things Lab -BEGIN PGP SIGNATURE- iQEzBAEBCAAdFiEEhrpukzGPukRmQqkK24/THMrX1ywFAmRya6sACgkQ24/THMrX 1ywTKAgAhiA0mnNSdHQNdcC07kujGCQAoliWmA4xLZ62eC/puXoeMPfIpAQDbDrJ nH9V9Ep2OaERUBRO0+/gcmnGWxRmeMYD1WGt/NlGlrCXRhpJjxxBZx5xSeIZRt6b DAtrVADJr650spRO/WuxmyStaPnZkXvefcz89Wl4qJUscrmNNnGGC1E1zmbh1V49 onJJNMemDalFyTPkA0uajh7CeSwEdpml4G+tBVh8T11k0F6DBVT0BdlsZyFrEHF6 KjB5Vlv2xVog13z7KNvWxfYn2s/Om4sTJMqCCCQr0vexpG0RXZBAEgMdI/xf5und Y3/0vyvY2vmrnE+UkuLUzDM0Yk32fQ== =dHmf -END PGP SIGNATURE- -- You received this message because you are subscribed to the Google Groups "qubes-devel" group. To unsubscribe from this group and stop receiving emails from it, send an email to qubes-devel+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/qubes-devel/ZHJrq0I4yBA1cXy6%40mail-itl.
Re: [qubes-devel] qrexec parser - !include-dir allows multiple params
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 On Fri, May 26, 2023 at 03:48:18PM +, Ben Grande wrote: > Issue report. > > Fails: > !include a b > Works: > !include-dir a b > > I believe that !include-dir should also throw an exception on invalid > number of params, but it currently doesn't. I did not understand why > !include can raise the exception and !include-dir, that has the same > code, doesn't. I can't confirm it, for me both fail. Which qrexec package versions do you have? - -- Best Regards, Marek Marczykowski-Górecki Invisible Things Lab -BEGIN PGP SIGNATURE- iQEzBAEBCAAdFiEEhrpukzGPukRmQqkK24/THMrX1ywFAmRw1wQACgkQ24/THMrX 1yxIeAf/Yc3wYavWlq6a+4CbPfWWXsXTdP6L2dqKMYga+Dpj2V21/NN7/5csYbxT h3DzojeSgO/I2Q3ltvcY3jA724dsd9WhXwfvH/bPXqulnZ6vROslVZhUBENGmo/x ZY2xTK+nTAhBOBxXyucNYPEaN/9NXVFEBssBNblEPmO4ep9Qgbvr1N2YMTJURQrZ Uj82wwJHud3HtoJpx6Xk96d3P7XKjz4PwFw8XVqeyCjk2WGPSGIDZtK3InKWpxJV kgAT12HHaq6TcDZXUS7s+ZFIzojUZhjBnG3PCgJnx+VbLlLbtkmhKieZG1BjQQsn xxdUSRbYpUItzxcFqSergC3Auql37w== =NpuG -END PGP SIGNATURE- -- You received this message because you are subscribed to the Google Groups "qubes-devel" group. To unsubscribe from this group and stop receiving emails from it, send an email to qubes-devel+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/qubes-devel/ZHDXBA2xtK63nJab%40mail-itl.
Re: [qubes-devel] [PATCH] Fix python3-qrexec missing on qubes-core-qrexec
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 On Fri, May 26, 2023 at 08:58:58AM +, Ben Grande wrote: > > -- > Benjamin Grande > > -- > You received this message because you are subscribed to the Google Groups > "qubes-devel" group. > To unsubscribe from this group and stop receiving emails from it, send an > email to qubes-devel+unsubscr...@googlegroups.com. > To view this discussion on the web visit > https://groups.google.com/d/msgid/qubes-devel/ZHB00gq0Ir/XWDqB%40personal-mutt. > From 84232c53e665eb012c87d44b481157c863aaf4e9 Mon Sep 17 00:00:00 2001 > From: Ben Grande > Date: Fri, 26 May 2023 08:54:46 + > Subject: [PATCH] Fix python3-qrexec missing on qubes-core-qrexec > > Signed-off-by: Ben Grande Thanks, applied. - -- Best Regards, Marek Marczykowski-Górecki Invisible Things Lab -BEGIN PGP SIGNATURE- iQEzBAEBCAAdFiEEhrpukzGPukRmQqkK24/THMrX1ywFAmRwn8sACgkQ24/THMrX 1yzrAgf9FzbnyeFYLw8mLEZ8KbDK185uFX3iz0Gag5SXnxq/uvy94iJw2PuH67bQ paq9rAGoXNXkPO3o9wha8aE5BKN10s4KZVRfWnY930zfzEsQKsXtOdsblOS/VIW4 v73lf/wf/+ZsOxE27TcvsiQrf4Mca5losARTtEDySGshMT/IaaRkTonRHcO9qORw NesWjcP3iNZp+aoqwu2vS70h2Hg16bFDg+7fnyE1ub65nad4BB5WCvzcSi1bwHid hiIFujbDTSYzmXi0WHAMlDeb4Kjm1w0ZCeD2yZkbNW9j1nlJbxMFHKTbwvQaho7B FvuouCOALq8ucSxEwNxQfKLWf3HCBw== =BHOc -END PGP SIGNATURE- -- You received this message because you are subscribed to the Google Groups "qubes-devel" group. To unsubscribe from this group and stop receiving emails from it, send an email to qubes-devel+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/qubes-devel/ZHCfyhWBbMn2a4nC%40mail-itl.
Re: [qubes-devel] vim-qrexec - A Qrexec companion for the policy breakers
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 On Thu, May 25, 2023 at 11:24:15PM +, Ben Grande wrote: > On 23-05-26 00:57:04, Marek Marczykowski-Górecki wrote: > > On Thu, May 25, 2023 at 10:18:43PM +, Ben Grande wrote: > > > On 23-05-25 11:45:45, Demi Marie Obenour wrote: > > > > On Thu, May 25, 2023 at 10:54:48AM +, Ben Grande wrote: > > > > > If the parser can be packaged to DomUs, that would make linting > > > > > policies > > > > > from any qube possible. These are the dependencies I mapped: > > > > > > > > > > qrexec > > > > > __init__ > > > > > exc > > > > > utils > > > > > policy.parser > > > > > > > > > > See the imports at: > > > > > https://codeberg.org/ben.grande.b/qubes-tools/src/branch/main/qubes-policy-lint > > > > > > > > That should definitely be doable. > > > > That should already be the case, qubes-core-qrexec should be installed > > in domU too. > > Hum, on Fedora yes, on Debian, incomplete. > > Fedora - expect qrexec denied: > $ qubes-policy > Request refused > Command Failed > > Debian - unexpected module not found: > $ qubes-policy > Traceback (most recent call last): > File "/usr/bin/qubes-policy", line 2, in > from qrexec.tools.qubes_policy import main > ModuleNotFoundError: No module named 'qrexec' Ah, that looks like a missing dependency on python3-qrexec. - -- Best Regards, Marek Marczykowski-Górecki Invisible Things Lab -BEGIN PGP SIGNATURE- iQEzBAEBCAAdFiEEhrpukzGPukRmQqkK24/THMrX1ywFAmRv85gACgkQ24/THMrX 1yyligf9E9Y+fyLF7fmjT9q4e8qS00KYRDB9W5ocrwUvW5+hUCBZlBMlMb6g1uPX Tl+jvwIegV1ivTXt6qJk3Su4RGot/SlTJ1r/i+u0sokS4I+NGJ+2qWV1jxQEHDnb sou/p2156+ufo0dkAB2XOm3tR5QQSQ1ODMdtZsVnsrFtE9LYxAMje4aSWBab0LEs YIT8Ila5VQ9miRgJfcTjdcPXPkVBXEPsE0KwdoB1Fra/skwFR7zSPFmnVVVoh3e9 W+HR0umTm1YRSQ+mwyxajeoCWRwgywDXiUqOBun6Eg2EJM60EJc3wck3Ynd8Idrf 9NsgsJA0EJEJ/FNOl3PRO9fPTYzVxw== =bJVk -END PGP SIGNATURE- -- You received this message because you are subscribed to the Google Groups "qubes-devel" group. To unsubscribe from this group and stop receiving emails from it, send an email to qubes-devel+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/qubes-devel/ZG/zmPw1sfbmeRkH%40mail-itl.
Re: [qubes-devel] vim-qrexec - A Qrexec companion for the policy breakers
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 On Thu, May 25, 2023 at 10:18:43PM +, Ben Grande wrote: > On 23-05-25 11:45:45, Demi Marie Obenour wrote: > > On Thu, May 25, 2023 at 10:54:48AM +, Ben Grande wrote: > > > If the parser can be packaged to DomUs, that would make linting policies > > > from any qube possible. These are the dependencies I mapped: > > > > > > qrexec > > > __init__ > > > exc > > > utils > > > policy.parser > > > > > > See the imports at: > > > https://codeberg.org/ben.grande.b/qubes-tools/src/branch/main/qubes-policy-lint > > > > That should definitely be doable. That should already be the case, qubes-core-qrexec should be installed in domU too. - -- Best Regards, Marek Marczykowski-Górecki Invisible Things Lab -BEGIN PGP SIGNATURE- iQEzBAEBCAAdFiEEhrpukzGPukRmQqkK24/THMrX1ywFAmRv58AACgkQ24/THMrX 1yyxeQf+JB0k8IskH/pyS0GokVsnyW2K3RCOUpdGdlwS6IZ0ok7/q4VeuEB0RGzm lavVrrkow7NguTBKSppKxxPEMq8GyNw4VdWP60R5QFP5+j/QzYk+vSAsv+mwAmmt RT39UjzqJYEa3WNBUpZFMmlO/TP6IXdwhzwobU7RlX2z/Y/uIQQn0eeyIR0+g+5C jRLuWuTw0cSKgm5N7Qd9dCEhhtvbBdTbQCnTZVJb1aW+jQDevR7VmGJOK026OsOI 79xn+s0sL/tr34XTzfuh2xszVVXD7t04ToE+y10oZDfv/LQ9+vVhQ9i8jzkiaxGd vXI6Q5DGkIP+H+bzrJJPDKFqrDNbxA== =gn2o -END PGP SIGNATURE- -- You received this message because you are subscribed to the Google Groups "qubes-devel" group. To unsubscribe from this group and stop receiving emails from it, send an email to qubes-devel+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/qubes-devel/ZG/nwA852xbb7BXd%40mail-itl.
Re: [qubes-devel] qubes-policy-lint and qubes-policy-editor-terminal
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 On Wed, May 24, 2023 at 10:29:07AM +, Ben Grande wrote: > On 23-05-19 14:52:57, Marek Marczykowski-Górecki wrote: > > Hi, > > > > Those look very useful! > > > > I have one comment to qubes-policy-edit-terminal: when using > > policy_get() (or policy_include_get()), you get a policy content and a > > token. Use that token in policy_replace() call to detect race conditions > > (when something else changes the same policy file in the meantime). > > Will add the token argument and let the exceptions handle the rest. > > Just one thing, the name "qubes-policy-editor-terminal" is non-ideal. I > just added "terminal" to the name because "qubes-policy-editor" was > taken by the GUI application implemented with: > https://github.com/QubesOS/qubes-desktop-linux-manager/pull/143 > > Can Qubes keep the standard of using "*-gui" for GUI applications? > Some use, some doesn't. In short, I am asking for the Qubes Team to > rename the current GUI app to qubes-policy-editor-gui, so the one > provided by this thread can be named qubes-policy-editor. Marta, what do you think? I think we can do that. > If the answer is no to the rename action, I will just add the token > argument. > > > > I am doing vim-qrexec, will notice when ready for review, it requires > > > the qubes-policy-lint for linting the policies from within Vim. So I > > > will wait for a resolution of this topic. > > > > > > Repository: https://codeberg.org/ben.grande.b/qubes-tools > > > > Would you like to submit those to the core-qrexec repository? > > Yes. Also take a look vim-qrexec to see if it is possible to be included > in qubes-core-qrexec: https://codeberg.org/ben.grande.b/vim-qrexec > > It is not complicated, but it is extensive and written in VimScript. > It can be used in DomUs and Dom0, but the lint tool can only be run in > Dom0. If you prefer, I can start another thread to better explain it. That would IMO makes sense. - -- Best Regards, Marek Marczykowski-Górecki Invisible Things Lab -BEGIN PGP SIGNATURE- iQEzBAEBCAAdFiEEhrpukzGPukRmQqkK24/THMrX1ywFAmRt6H0ACgkQ24/THMrX 1ywh9Qf+KkqZO75sI69MaVhfTif82bl0hcJy+S/sTYm5DXOmthDICQ3Af/KYmaQT ATyZXzE3eJt6zvUmL/v7t+b24KRqh43/AWrHAxjZOvzCFlq08QavKrna2Yaz4w5I X3tR1RO07R/aCH8XRi+erxDMslXz8jKUVWKF2LIvcPPzGnj/zJW5oQOF/sbra7Kf WyDWOxxHkW3/2afVIWgU0nLssiT1cQfJd6NfofBc0Gx+5ZpPgc5BNyo9OtR2zRAp 3qhS8A/elFriuF8QzoPI+HAAvrO4fTPgPvGLSmNAjOOyo75BtFrhyW7dSV6R4OSn GxVE9hnMZuvkSn1PEhuO88BHOd+LqQ== =0Zd3 -END PGP SIGNATURE- -- You received this message because you are subscribed to the Google Groups "qubes-devel" group. To unsubscribe from this group and stop receiving emails from it, send an email to qubes-devel+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/qubes-devel/ZG3ofcu%2BMDEeoo27%40mail-itl.
Re: [qubes-devel] qubes-policy-lint and qubes-policy-editor-terminal
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 Hi, On Thu, May 18, 2023 at 06:20:06PM +, Ben Grande wrote: > I created a standalone lint tool for the Qrexec policies, the name is > qubes-policy-lint. It is a wrapper around qrexec.policy.parser > TestPolicy|StringPolicy. > > You can lint normal policies: > qubes-policy-lint /etc/qubes/policy.d/*.policy > Or policies included by !include-service: > qubes-policy-lint /etc/qubes/policy.d/include/* > > There is also qubes-policy-edit-terminal, an alternative to > qubes-policy-editor by marmarta for terminal users. By default, it > opens the user policy, but you can specify any policy that is already > registered in /etc/qubes/policy.d/*.policy or > /etc/qubes/policy.d/include/. You can use it with any editor, as you are > editing a temorary copy of the policy, it doesn't matter. Those look very useful! I have one comment to qubes-policy-edit-terminal: when using policy_get() (or policy_include_get()), you get a policy content and a token. Use that token in policy_replace() call to detect race conditions (when something else changes the same policy file in the meantime). > I am doing vim-qrexec, will notice when ready for review, it requires > the qubes-policy-lint for linting the policies from within Vim. So I > will wait for a resolution of this topic. > > Repository: https://codeberg.org/ben.grande.b/qubes-tools Would you like to submit those to the core-qrexec repository? > Attached is my public keys for signing for code (0x00C64E14F51F9E56) and > mail (0x1B7314BF0CCC9687). - -- Best Regards, Marek Marczykowski-Górecki Invisible Things Lab -BEGIN PGP SIGNATURE- iQEzBAEBCAAdFiEEhrpukzGPukRmQqkK24/THMrX1ywFAmRncSgACgkQ24/THMrX 1yxfPQgAieh5yzXC/xsod05WzOaxx4f5XOaNy1MCytK3djJcPmE5AVgHIIPQzqtt HqSPZFrZYKB7MlknUKhztu/auxQw1GR2u3BTQIhDmSpmFVYwjYWaZQPpHiMeQ05P pM1u67+eEFsFHjPEt0mYaDvxA0HIPuIY3+D2ZLIAfUpqUwf3r88GsPJaXXL51OoH 04NJS4fAzL1UW80gk3TCt8aqkc0f5iDrG4ccVDjIn6mEhq01NGXLTPn6JMrvcQCb THhhvWcB0TX+qF/FmKyuAEVUJNSDHCYOwvvuqHTIVuD/9pb1ctHWdCJxBy4Y1xgb 99fckFvJlILcm1UslEdatwPcd/UjPw== =H9K+ -END PGP SIGNATURE- -- You received this message because you are subscribed to the Google Groups "qubes-devel" group. To unsubscribe from this group and stop receiving emails from it, send an email to qubes-devel+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/qubes-devel/ZGdxKa5xF1YlOrnZ%40mail-itl.
Re: [qubes-devel] [PATCH] Fix missing include in RPC names in admin_client
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256
On Thu, May 18, 2023 at 05:49:31PM +, Ben Grande wrote:
> Seems like a copy and paste issue.
> As of know, if I try to replace include/admin-local-ro, as it is using
> the path /etc/qubes/policy.d, the file is placed there under the name
> admin-local-ro.policy.
> For reviewers, check /var/log/qubes/policy-admin.log.
Thanks, applied.
>
> --
> Benjamin Grande
>
> --
> You received this message because you are subscribed to the Google Groups
> "qubes-devel" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to qubes-devel+unsubscr...@googlegroups.com.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/qubes-devel/ZGZlKwviLqvWCfJW%40personal-mutt.
> From e684e4c5de379c7412fd256adaf243b73cbff040 Mon Sep 17 00:00:00 2001
> From: Ben Grande
> Date: Thu, 18 May 2023 17:32:06 +
> Subject: [PATCH] Fix missing include in RPC names in admin_client
>
> Signed-off-by: Ben Grande
> ---
> qrexec/policy/admin_client.py | 4 ++--
> 1 file changed, 2 insertions(+), 2 deletions(-)
>
> diff --git a/qrexec/policy/admin_client.py b/qrexec/policy/admin_client.py
> index c28c2f2..f969260 100644
> --- a/qrexec/policy/admin_client.py
> +++ b/qrexec/policy/admin_client.py
> @@ -57,13 +57,13 @@ class PolicyClient:
> self.call("policy.Replace", name, token + "\n" + content)
>
> def policy_include_replace(self, name: str, content: str, token="any"):
> -self.call("policy.Replace", name, token + "\n" + content)
> +self.call("policy.include.Replace", name, token + "\n" + content)
>
> def policy_remove(self, name: str, token="any"):
> self.call("policy.Remove", name, token)
>
> def policy_include_remove(self, name: str, token="any"):
> -self.call("policy.Remove", name, token)
> +self.call("policy.include.Remove", name, token)
>
> def policy_get_files(self, name: str):
> result = self.call("policy.GetFiles", name)
> --
> Benjamin Grande
>
- --
Best Regards,
Marek Marczykowski-Górecki
Invisible Things Lab
-BEGIN PGP SIGNATURE-
iQEyBAEBCAAdFiEEhrpukzGPukRmQqkK24/THMrX1ywFAmRnbYsACgkQ24/THMrX
1ywVsQf3a2z4HfxPy5/mjI46wPnHYF9cWUTfm2WhxRVbRzi/4ZZ+Y5pgekB391bp
Z35mPlx3R80Op/O+8MY/bjqDsZq5tg4SBRfLAMo16NdegUxqJ8fHvYsSPOBYP07v
F1+p84C7MgsNAOMfC1To6O6gmlI49oXIXEFtLWfxhcYz8oiOnUSvE8ZqBixewBnn
3NOX0g4D6U4OckXo0x9FDBrUcRg2P+JspGDJ9EOoQ8UjixVrzFGdRKMAmVTJ8PIb
qOg3o0uQsdh3zciF2XwSi/q2a5U2zoI3SRV0cUf1gD/okcHp3aPREvA9TUzyVubm
ftACp7FMgvBTBJ9cTnHRXBDQqa0O
=K8Jl
-END PGP SIGNATURE-
--
You received this message because you are subscribed to the Google Groups
"qubes-devel" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to qubes-devel+unsubscr...@googlegroups.com.
To view this discussion on the web visit
https://groups.google.com/d/msgid/qubes-devel/ZGdti976yOjdwhoC%40mail-itl.
Re: [qubes-devel] Proposal 2: Make Qubes OS tools (qvm- and qubes-) consistent with flags and other arguments
hat different VM types may not only different allowed properties, but even different meanings of the same property. See for example 'template' property for AppVM and DispVM. We can probably collect them for all classes and then annotate differences, but I'm not sure how helpful that would be. > * Make the format of arguments providing lists consistent across tools. > E.g. `qvm-ls` has `--tags` with list separated with spaces, not consistent > with --fields and other cases with comma separation. Why not commas? Theoretically it would allow using tags with arbitrary names, including comas. But we don't allow them anyway, so yes, can be comas. Any other places where you found it inconsistent? > * Make tools faster with output, if possible. > E.g. `qvm-volume list` takes ten times more time than `lvs` to provide > similar output for some reason. Up to several seconds in my case. It slows > down every automation process that uses these tools. We did some optimization for qvm-ls before, I guess it's time for qvm-volume now. Thanks for all the comments! - -- Best Regards, Marek Marczykowski-Górecki Invisible Things Lab -BEGIN PGP SIGNATURE- iQEzBAEBCAAdFiEEhrpukzGPukRmQqkK24/THMrX1ywFAmPPuJYACgkQ24/THMrX 1ywItQf/cc7bJ4RaZR1N6x+hKtysdWGH8Oei2G1vZypYIePtUIOC+kYxdsykVb6Z g2QNN2MO8Av1Dipumtk6OU6lPQWjiGnyyTR9IdvY7PfZjEcPS3XcldVo6To76xzd 7QkE3RZcRbA53fTqc0UJHp5QuxZqP20G+irqSUYg6yrI+1bgCdu3xsddai3h+hpk KqPyWCze2Bwp11sIQWHLcgT4GgNJvQ/jUUhnh3SrGOfeWAXQ1O/K6K1xbSM5iwhq c3dfL2zUL2LFGyP6v6MNNbsrrUKBHboV7XsJkgWV7A78yVI1ew7G2wnWOs8hlspw LyenXMB0sOVVlH7KAKikOM1NL+yFdg== =WorB -END PGP SIGNATURE- -- You received this message because you are subscribed to the Google Groups "qubes-devel" group. To unsubscribe from this group and stop receiving emails from it, send an email to qubes-devel+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/qubes-devel/Y8%2B4lpaBKOSBdb1G%40mail-itl.
Re: [qubes-devel] Default branch switched to 'main'
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 On Mon, Nov 28, 2022 at 01:40:31AM -0500, Demi Marie Obenour wrote: > On Mon, Nov 28, 2022 at 04:02:50AM +0100, Marek Marczykowski-Górecki wrote: > > Hello, > > > > Since some time already, new repositories in QubesOS github org had > > 'main' as default branch. I've just switched default branch to 'main' > > for existing repositories too. > > For transitional period, both 'master' and 'main' branches will exist, > > and will be kept in sync (there is a bot for that). So, all repo clones, > > builder.conf files etc should remain valid. Existing pull requests > > should remain unaffected too. > > My current plan is to keep this transitional period at least until R4.1 > > EOL. The reasoning is that any existing build/devel environment for > > R4.1 should remain functional as long as R4.1 is supported. But any new > > environment for R4.2 should use new branch names already. > > Example R4.2's builder.conf qubes-builder (v1) is updated already. The > > one for qubes-builderv2 will be updated shortly. > > Does not work for me: > > -> Updating sources for builder-github... > --> Fetching from origin main... > fatal: couldn't find remote ref main > make: *** [Makefile:224: builder-github.get-sources] Error 1 I went through repos list again, hopefully haven't missed anything important this time... - -- Best Regards, Marek Marczykowski-Górecki Invisible Things Lab -BEGIN PGP SIGNATURE- iQEzBAEBCAAdFiEEhrpukzGPukRmQqkK24/THMrX1ywFAmOGK0oACgkQ24/THMrX 1yxWCgf7BmLvUwbMncw1/57OA3h3ZkWpgV/kWfd4gP6U89wOu776ENz6Q6Qdz9hw TtrfQZAnHugODy/uNCqpWxTMj3idWdojWLNxBt5DoACloqhUy9AAQj79wU7YupNU FIBLqE350Oe5jmHJGGrzZKz3Ln0MVR+xxy/hIo9F/4ZV3jqCivR+j8KSoTyhgl80 7lF1NxNG54zJ3lHD0ZH88d0GK+aWuWO2mleaj2Cw2iSUbl+gIFM0jkRNoNcQzjIN ZkCaAtILvpqdDsvK7+fKetHCfKMrY7w/vHElSNUtbZiaGQySZ08JAQahiqVRqGO6 0ixTrQFJF3s04hTekWzgqBN4+iIocg== =rLX1 -END PGP SIGNATURE- -- You received this message because you are subscribed to the Google Groups "qubes-devel" group. To unsubscribe from this group and stop receiving emails from it, send an email to qubes-devel+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/qubes-devel/Y4YrSzc2ee4TPD3M%40mail-itl.
Re: [qubes-devel] qubes-doc & rtd
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 On Tue, Nov 01, 2022 at 12:45:33PM +0100, mm wrote: > Hi Marek, hi Andrew, hi Tobias, > > Marek, I merged your pull request, also merged your changes into master and > added some enhancements and created a pull request. > > Here you could review it > https://github.com/maiska/qubes-translation-utilz/pull/2 > > Either way, one could try it out, there should be no more undefined or > unknown label warnings when rendering the rst docs > and thus could safely imho go and convert the documentation and host it on > RTD. > > Here is a README.md instead of spamming via email > https://github.com/maiska/qubes-translation-utilz/blob/master/README.md > > the configuration should be more readable also: > > https://github.com/maiska/qubes-translation-utilz/blob/master/md2rst/config.toml > > Please let me know if I have to fix further or this suffices. I think the current version of scripts is good :) Thanks! There are sphinx warning remaining, but there are not that many of them and can be fixed manually (things like underscores for headers, or single space at the beginning of line interpreted as unexpected indentation). The only other issue I consider a blocker (but hopefully should be easy to fix) is index.rst. The sidebar index is great, but in its current form it's hard to use - it's very long. I added section captions there and it helped a bit, but I think those should be folded by default (similar folding like sections of the current page). I tried setting `collapse_navigation`[1], but it didn't work. Any other ideas? BTW, while looking for related option, I found you can use `:glob:` in toctree, to add everything from given subdirectory. This way we can have some section filled automatically (as long as directory structure reflects sections, but it is the case in most cases). I uploaded current version to https://qubes-doc-rst.readthedocs.io/en/latest/ (I haven't fixed all sphinx warnings there, so few places may have wrong indentation). I haven't updated translated pages - those are still from previous iteration. Source of the above is at https://github.com/marmarek/qubes-doc/tree/work4/ Another thing that IMO would be better, is to keep the "introduction" page as part of the main website, and only link to it from the documentation. Should be easy with the redirects extension (as already done for HCL and few others). The next question is what to do about qubes-doc repo. We can either replace the current content with converted to rst (and keep markdown in a separate branch, for historical reasons), or create new one (qubes-doc-rst?), and basically archive qubes-doc. In any case, the _doc submodule should be replaced with generated redirects to the new documentation. IMO it can be put into qubesos.github.io repository directly, as it shouldn't really change (it's only to keep existing documentation links on mailing list, forum etc working, shouldn't be used for new content). [1] https://sphinx-rtd-theme.readthedocs.io/en/stable/configuring.html > Otherwise I will briefly handson evaluate weblate locally and report back. Do you have any update on weblate? > @Andrew, > > regarding the minimal debian jekyll vm, here is a way with a template and an > app vm. > > qvm-clone debian-11-minimal jekyll-tvm > > in jekyll-tvm: > apt install qubes-core-agent-networking > apt install ruby-full build-essential zlib1g-dev vim > apt install qubes-core-agent-passwordless-root > apt install firefox-esr git > > in jekyll-app-vm: > echo '# Install Ruby Gems to ~/gems' >> ~/.bashrc > echo 'export GEM_HOME="$HOME/gems"' >> ~/.bashrc > echo 'export PATH="$HOME/gems/bin:$PATH"' >> ~/.bashrc > source ~/.bashrc > gem install jekyll bundler > find . -name gem # '/home/user/.local/share/gem/' > bundle config set --local path '/home/user/.local/share/gem/' > git clone -b new-master --recursive > https://github.com/QubesOS/qubesos.github.io.git; cd qubesos.github.io.rtd/ > bundle install > bundle exec jekyll serve --incremental > > > > All the best, > > m > > > > On 10/4/22 12:29, Marek Marczykowski-Górecki wrote: > > Hi, > > > > Thanks for the update. Don't worry about the schedule - while we do want > > to finish this soon, it doesn't need to be yesterday. > > > > > > On Tue, Oct 04, 2022 at 06:54:45AM +0200, mm wrote: > > > Hello Marek, hello Andrew, > > > > > I can have spare time starting Sunday to focus & reply. > > > > > (Please, Marek, recall that i have pointed out mid September that I am > > out off the map > > > > > basically from 15.09 till 8.10.) > > > > > Nevertheless tried to fix different issues in som
[qubes-devel] Default branch switched to 'main'
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 Hello, Since some time already, new repositories in QubesOS github org had 'main' as default branch. I've just switched default branch to 'main' for existing repositories too. For transitional period, both 'master' and 'main' branches will exist, and will be kept in sync (there is a bot for that). So, all repo clones, builder.conf files etc should remain valid. Existing pull requests should remain unaffected too. My current plan is to keep this transitional period at least until R4.1 EOL. The reasoning is that any existing build/devel environment for R4.1 should remain functional as long as R4.1 is supported. But any new environment for R4.2 should use new branch names already. Example R4.2's builder.conf qubes-builder (v1) is updated already. The one for qubes-builderv2 will be updated shortly. - -- Best Regards, Marek Marczykowski-Górecki Invisible Things Lab -BEGIN PGP SIGNATURE- iQEzBAEBCAAdFiEEhrpukzGPukRmQqkK24/THMrX1ywFAmOEJNkACgkQ24/THMrX 1yxExgf/TyFKg3F70t1jD+qGjjfqD4/vPhJeCr5DqnTs50/qDwIH3tooE62+Wtl+ DJYQwBxKaRMhErE5Sj0My0AWMGSvYMRgHjlDRQA4vOKu7FMtGQIJyZWXmf7WwUiv rnhCKa5M16Kj3Ne3Jwulg9U8Yjhqr2L9633pLkuOotCQxKeZCyBXlMc1dTK6DzZH wH5Smgh5x2AY5VX4KeSg5HUu/rtRFjxXu4BvpmuwnH8+yg3hoI7dgCTvN56HyooT 0dQWvp5Bc8Xq91rbaNRBiyyUTViGbX3nF26N/zjCvorPChxnJATmJR2YxYk4LQk9 Bq2YlY2176Uz6OeT9/TjLTY/nmVkqA== =J6iF -END PGP SIGNATURE- -- You received this message because you are subscribed to the Google Groups "qubes-devel" group. To unsubscribe from this group and stop receiving emails from it, send an email to qubes-devel+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/qubes-devel/Y4Qk2o2mRjSvbQeq%40mail-itl.
Re: [qubes-devel] qubes-doc & rtd
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 On Tue, Nov 01, 2022 at 12:45:33PM +0100, mm wrote: > Hi Marek, hi Andrew, hi Tobias, > > Marek, I merged your pull request, also merged your changes into master and > added some enhancements and created a pull request. > > Here you could review it > https://github.com/maiska/qubes-translation-utilz/pull/2 > > Either way, one could try it out, there should be no more undefined or > unknown label warnings when rendering the rst docs > and thus could safely imho go and convert the documentation and host it on > RTD. > > Here is a README.md instead of spamming via email > https://github.com/maiska/qubes-translation-utilz/blob/master/README.md > > the configuration should be more readable also: > > https://github.com/maiska/qubes-translation-utilz/blob/master/md2rst/config.toml > > Please let me know if I have to fix further or this suffices. Thanks. I'm a bit busy this and the next week, but maybe I'll manage to take a look. Otherwise, after 11th of November. Do you have somewhere a conversion output pushed? > Otherwise I will briefly handson evaluate weblate locally and report back. Sounds like a good plan. > @Andrew, > > regarding the minimal debian jekyll vm, here is a way with a template and an > app vm. > > qvm-clone debian-11-minimal jekyll-tvm > > in jekyll-tvm: > apt install qubes-core-agent-networking > apt install ruby-full build-essential zlib1g-dev vim > apt install qubes-core-agent-passwordless-root > apt install firefox-esr git > > in jekyll-app-vm: > echo '# Install Ruby Gems to ~/gems' >> ~/.bashrc > echo 'export GEM_HOME="$HOME/gems"' >> ~/.bashrc > echo 'export PATH="$HOME/gems/bin:$PATH"' >> ~/.bashrc > source ~/.bashrc > gem install jekyll bundler > find . -name gem # '/home/user/.local/share/gem/' > bundle config set --local path '/home/user/.local/share/gem/' > git clone -b new-master --recursive > https://github.com/QubesOS/qubesos.github.io.git; cd qubesos.github.io.rtd/ > bundle install > bundle exec jekyll serve --incremental > > > > All the best, > > m > > > > On 10/4/22 12:29, Marek Marczykowski-Górecki wrote: > > Hi, > > > > Thanks for the update. Don't worry about the schedule - while we do want > > to finish this soon, it doesn't need to be yesterday. > > > > > > On Tue, Oct 04, 2022 at 06:54:45AM +0200, mm wrote: > > > Hello Marek, hello Andrew, > > > > > I can have spare time starting Sunday to focus & reply. > > > > > (Please, Marek, recall that i have pointed out mid September that I am > > out off the map > > > > > basically from 15.09 till 8.10.) > > > > > Nevertheless tried to fix different issues in some spare time, such as > > embedding videos, toctree etc. > > > > > I will push my final version on master asap. (Still haven't gotten to > > the PR/merge/refactor), suggest to wait till Sunday. > > > > > If that is not possible there are several issues to be considered: > > > > > 0. please pay attention to config.toml and conf.py from master and the > > files in preparation. > > > > > 1. which rst files are to be copied (there are 3 atm, since the most > > issues should be fixed via rstwriter2), which to be removed, > > > > > different extensions to be configured such as redirects (I suggest > > leaving an empty hcl.rst (downloads etc) with a redirect, to be > > populated in a > > > > > later stage via jinja scripting), new strikeout extension and new > > role, video directives, which markdown files are also to be copied > > > - is doc.md the right one etc? latex documents are rendered correctly > > (toctree req) > > > > I took toctree-example.rst and manually synced with recent doc.md. It > > seems to work, including PDF version. The PDF could use explicit TOC at > > the beginning, but it is in PDF metadata, so can be seen in the side > > panel of PDF viewer. > > > > > > > 2. !! Problem that should have a solution: > > > > > f.ex.https://qubes-doc-rst.readthedocs.io/en/latest/user/troubleshooting/installation-troubleshooting.html > > > > > in the sentence: > > > > > "Here are the steps to fix this. Note that this allows sys-net and > > sys-usb to take complete control of the system, as described in the FAQ > > here:" > > > there should be a cross reference to FAQ VT-d iommu section but is > > not. (with my version this is also a problem) > > > > > Unfortunately the d
Re: [qubes-devel] Retiring R4.0 repositories
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 On Mon, Oct 24, 2022 at 11:24:46PM +0200, Marek Marczykowski-Górecki wrote: > Hi all, > > I'll be removing R4.0 repositories from yum.qubes-os.org shortly. As > README there states, the archive is at > https://qubes.notset.fr/archive/repo/yum/. > > It shouldn't affect anyone using supported version, and those still > running R4.0 (stats say a little over 10k users...) wouldn't receive any > updates from there anyway (we don't build new packages there anymore). > It will result in an error when checking for updates on R4.0 systems, > but that actually can be a good thing - yet another hint that R4.0 > systems are not supported anymore. Sadly, this also breaks upgrade to R4.1: https://github.com/QubesOS/qubes-issues/issues/7838 I'll delay complete removal, but still will cleanup templates repositories (putting a metalink redirect to the archive instead). - -- Best Regards, Marek Marczykowski-Górecki Invisible Things Lab -BEGIN PGP SIGNATURE- iQEzBAEBCAAdFiEEhrpukzGPukRmQqkK24/THMrX1ywFAmNaaokACgkQ24/THMrX 1yzKigf7BbrRDi5arRGEOJltxfpMWWpf40yS/Gsmf/pTZE2cIHOvClHZfCHTW5WC HRHa4Vqkn9wqa7l6pT7EYlNKh7qv2SC/Yh2Ll0ulD9+NQv3bY2i7w9hzue6lpOSN ff8atvIybOhAzOkZx9b8lBga5j6Lps7Exn0SwZzjBglLiH+0Xfpmb49FXqDGnNA7 d+bbuxXPyZOWfZqUFlcR194JSxfGAQfmUX+EYFID8hsIgZOJ6SSm+lyIrvXBkbRD trvdnDeOC9coPnhtKWKxy3vTZGU9Va3c1YmDOhUEoFSFe2Y25zddpU4HH7VjULka wauGyToXRfN8MtbAiObF7iBKQ7U59g== =kOCp -END PGP SIGNATURE- -- You received this message because you are subscribed to the Google Groups "qubes-devel" group. To unsubscribe from this group and stop receiving emails from it, send an email to qubes-devel+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/qubes-devel/Y1pqiFNPICA2eDfb%40mail-itl.
[qubes-devel] Retiring R4.0 repositories
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 Hi all, I'll be removing R4.0 repositories from yum.qubes-os.org shortly. As README there states, the archive is at https://qubes.notset.fr/archive/repo/yum/. It shouldn't affect anyone using supported version, and those still running R4.0 (stats say a little over 10k users...) wouldn't receive any updates from there anyway (we don't build new packages there anymore). It will result in an error when checking for updates on R4.0 systems, but that actually can be a good thing - yet another hint that R4.0 systems are not supported anymore. - -- Best Regards, Marek Marczykowski-Górecki Invisible Things Lab -BEGIN PGP SIGNATURE- iQEzBAEBCAAdFiEEhrpukzGPukRmQqkK24/THMrX1ywFAmNXAp4ACgkQ24/THMrX 1yzeGQf9FW9DUptd1wuenc6Rjmr/++WGtME5IL0SCI7lYLpnyt91B6P587tqU7e/ c0WYL82PkdndueIpux1uGGinNlM2GECWofrquVosyt16kVYW6TICLWkj+bnEEv+3 7gwrZFlrmNuJaIztFWXolhKm7s3w+O/YEsFrK7/+gQpAT69vvOAqk9kDplRt43EM 2hvaMeyy1UWp/LPR1AfuUgTMGXia1yXq7ZHDv8gA49tVINcudEZJFgxGxHze0QNo jgOeuwxyGUdaZEvshGsRgCBuLZDBEMMEI5n1rP9VYLZolz47Immss1/Pg7Y0cScy GNAfYuQ3ZMrgE8uM8i/nNzgr1LClKw== =owrX -END PGP SIGNATURE- -- You received this message because you are subscribed to the Google Groups "qubes-devel" group. To unsubscribe from this group and stop receiving emails from it, send an email to qubes-devel+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/qubes-devel/Y1cCnh/ToX%2BIYR1s%40mail-itl.
Re: [qubes-devel] Current problems with Qubes 4.1
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 On Thu, Oct 13, 2022 at 03:57:07PM +0100, 'unman' via qubes-devel wrote: > There are numerous issues being raised about the current performance of > Qubes - graphical glitches, system hangs, random reboots, unstable > service qubes, etc. Some of these are notable when qubes are starting or > shutting down, (which may explain why some people link this to running > updates.) You can see this in numerous Forum posts and on GitHub. > > I think , as djb posted today, this is particularly obvious when > transitioning from 4.0 to current 4.1. (When one of our supporters finds > this, I think we are in trouble.) > I posted about some of the issues in the testing section of Forum, but > no one else commented. I was reporting there issues that affected at > least 5 users, two of them using certified hardware. > Again, if users of certified hardware encounter these problems, we are > in trouble. > > For my part I can probably date these issues back to some time in the > past 6 weeks. Prior to that my Lenovos were solid - I was amazed at the > troubles that some users reported, and my support calls were limited. > This isn't the case now. > > It could be that these issues only affect older hardware - I don't think > so. Or perhaps the current system stresses components so that some > failing elements show otherwise hidden flaws. > > Whatever the case, there's a major issue that needs to be addressed. > I thought of rolling back some systems to see if I can identify a time > before the flood, and then bisect to find which packages might be > responsible. > Would this make sense? > Would it be worthwhile? > Are there any thoughts on the current situation? > What would be the best way forward, and how can we contribute to the > effort? Are those by any chance using kernel-latest? There are numerous issues with 5.19.x kernel, but I believe the default (5.15.x) isn't affected. - -- Best Regards, Marek Marczykowski-Górecki Invisible Things Lab -BEGIN PGP SIGNATURE- iQEzBAEBCAAdFiEEhrpukzGPukRmQqkK24/THMrX1ywFAmNIjOMACgkQ24/THMrX 1yyIfAgAgf4A2/nw9Bf7wMZ5pjua4S+Fs5fsI+Tz8T7K9aeYmqkZGL8711m2suB2 4Z3d63FHE3pROc6Re4Xj9buDs0omgkyPck0GiB3EtyGmLyvq4f7oDGL9C4Z9VK+a LU1x6MG0F8twNR8nn2LqR7VVw+MWXqbXb1HF44X2gRbkVscQk6riu3vq5zrxuWPU MRKRtKN7S7BkwqefVvHSSjsWSMSpuSfXzUf3PyRXP462qBnpvDs84XhsRFHI0dEl vDyfkWMhs4Oi/5eT9oULMEljRIXfriGOWIwCevMVEuhWXqV/iMgiv0m/12EKLfrZ +CypSQOIx5Ksfa85zAO25DGiVJXXDw== =KDu7 -END PGP SIGNATURE- -- You received this message because you are subscribed to the Google Groups "qubes-devel" group. To unsubscribe from this group and stop receiving emails from it, send an email to qubes-devel+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/qubes-devel/Y0iM5IAWKVsAb25O%40mail-itl.
Re: [qubes-devel] qubes-doc & rtd
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 Hi, Thanks for the update. Don't worry about the schedule - while we do want to finish this soon, it doesn't need to be yesterday. On Tue, Oct 04, 2022 at 06:54:45AM +0200, mm wrote: > Hello Marek, hello Andrew, > > I can have spare time starting Sunday to focus & reply. > > (Please, Marek, recall that i have pointed out mid September that I am out > off the map > > basically from 15.09 till 8.10.) > > Nevertheless tried to fix different issues in some spare time, such as > embedding videos, toctree etc. > > I will push my final version on master asap. (Still haven't gotten to the > PR/merge/refactor), suggest to wait till Sunday. > > If that is not possible there are several issues to be considered: > > 0. please pay attention to config.toml and conf.py from master and the files > in preparation. > > 1. which rst files are to be copied (there are 3 atm, since the most issues > should be fixed via rstwriter2), which to be removed, > > different extensions to be configured such as redirects (I suggest leaving an > empty hcl.rst (downloads etc) with a redirect, to be populated in a > > later stage via jinja scripting), new strikeout extension and new role, video > directives, which markdown files are also to be copied > - is doc.md the right one etc? latex documents are rendered correctly > (toctree req) I took toctree-example.rst and manually synced with recent doc.md. It seems to work, including PDF version. The PDF could use explicit TOC at the beginning, but it is in PDF metadata, so can be seen in the side panel of PDF viewer. > 2. !! Problem that should have a solution: > > f.ex.https://qubes-doc-rst.readthedocs.io/en/latest/user/troubleshooting/installation-troubleshooting.html > > in the sentence: > > "Here are the steps to fix this. Note that this allows sys-net and sys-usb to > take complete control of the system, as described in the FAQ here:" > there should be a cross reference to FAQ VT-d iommu section but is not. (with > my version this is also a problem) > > Unfortunately the documentation (sphinx referencing via roles, perhaps the > implementation?) is not saying anything how to handle punctuation with > sections and cross ref with ref, > > so as of the moment I do not have an idea, apart from the basic stuff. Yes, I hit similar issues elsewhere. Most of issues like this I fixed by importing objects.inv and taking references from there (this is also pushed to the PR), but there are still few corner cases like the noted above. It seems '&' is handled differently by markdown and sphinx. All the sphinx warnings fit for me on one screen, so I think those few remaining cases can be fixed manually, there is no need to make the converter perfect. > > I also tried explicit automatic labeling above each section with a directive > (.. _id-of-section) - did not work out > > 3. different new files to be considered: > f.e.x 2 versions of the privacy content, how to edit the documentation - > markdown & rst version, visual style guide etc Yes, I left some of them on the old site (with matching redirects), but this needs to be sorted out. > 4. what is done so far on master > > -- video directives > > -- toctree index, notes, schedules, upgrade, how to restore > > -- section cross referencing small fixes > > -- svg conversion to png for selected files and replacement in rst docs > > -- convert leftover markdown links in rst files > > -- markdown redirects > > -- added directives for warning & note (can be used also for indicating > translated content) > -- anything i forgot > > 5. weblate - localization platform should be the way to go imho (sry not a > big fan of transifex rn, weblate is OS etc, > some more objective analysis will follow), there are several issues to be > clarified, wip, tails guys need good questions to work with > - will be done on sunday > 6. anything i forgot, did not address, mentioned too briefly or not clarified > i will address on sun > (if it is still needed) > > all the best, > m > > On 10/2/22 18:24, Marek Marczykowski-Górecki wrote: > > On Tue, Sep 27, 2022 at 01:15:56AM +0200, Marek Marczykowski-Górecki > > wrote: > > > On Mon, Sep 26, 2022 at 11:33:22PM +0200, mm wrote: > > >> Hi Marek, > > >> > > >> > > >> On 9/26/22 00:01, Marek Marczykowski-Górecki wrote: > > >>> Hi M, > > >>> > > >>> In fact, I'm working on translation-utilz right now too. Marta used > > her > > >>> google-foo and found this gem: > > >>> https://github.com/SamWilsn/docutil
Re: [qubes-devel] qubes-doc & rtd
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256
On Tue, Sep 27, 2022 at 01:15:56AM +0200, Marek Marczykowski-Górecki wrote:
> On Mon, Sep 26, 2022 at 11:33:22PM +0200, mm wrote:
> > Hi Marek,
> >
> >
> > On 9/26/22 00:01, Marek Marczykowski-Górecki wrote:
> > > Hi M,
> > >
> > > In fact, I'm working on translation-utilz right now too. Marta used her
> > > google-foo and found this gem:
> > > https://github.com/SamWilsn/docutils-rst-writer
> > >
> > this looks very nice!! :) Thanks Marta! :)
> >
> > > So, I replaced most of the qubesrstwriter2.py with just this thing and
> > > it's almost flawless (especially tables, images etc work out of the
> > > box).
> >
> > OK, thanks for the PR, I'll merge into and get rid of the obsolete stuff
> > from my branch this days.
> >
> > I have some weird customized fixes all over, but this should work.
I spent some more time on polishing the converter (all pushed to the
same PR), and I think it's good enough already. There are few remaining
issues that Sphinx complains about, but at least some of them look like
issues already present in the original markdown files, and can be fixed
in the RST version manually. I'd prefer it this way (for this category
of issues), because Sphinx gives much better error reporting than
jekyll, so it's easier to iterate.
The rendered content can be seen at
https://qubes-doc-rst.readthedocs.io/en/latest/
And the converted source at https://github.com/marmarek/qubes-doc/tree/work3/
Note the above has already enabled PDF+ePUB version, and German and
Spanish translations (although most content is not translated yet).
I did also used your markdownredirector to generate redirects to RTD,
here:
https://github.com/QubesOS/qubes-doc/pull/1272
It's deployed to wwwpreview.qubes-os.org. It works for most links, for
example
https://wwwpreview.qubes-os.org/doc/secondary-storage/
But, htmlproofer complains about links to specific sections - which
indeed are broken now ('#' part does not survive redirect). For example:
https://wwwpreview.qubes-os.org/doc/#troubleshooting
I don't think that's a big issue in practice, but will require adjusting
htmlproofer call.
Anyway, I see further steps as:
1. Review and merge (or reject) current PRs to qubes-doc. They will
become completely obsolete after conversion. Some of them are waiting
for my feedback...
2. Convert the whole qubes-doc repo to ReST format, and connect to
readthedocs.org as doc.qubes-os.org (any better idea for the domain?)
3. Disconnect qubes-doc submodule from qubesos.github.io repo, and
replace with generated redirects (the content of PR 1272 above).
4. Incrementally fix remaining issues in rst files (at this point, I
don't see any critical ones). Some I see Maya fixed already in the
fixed-rst-errors dir.
5. Adjust documentation contributing guidelines for the new format (this
page actually has rst format issues after conversion, but I haven't
bothered to fix them, because the content would need significant change
anyway).
And then, translation-related:
6. Cleanup our transifex project (remove previous attempts, like
doc-related markdown files)
7. Upload rst version (already done, but will need re-uploading after
final conversion).
8. Setup CI job to pull translations to qubes-translated repo (it's a
single transifex client call, I already have it ready to go from
previous attempt).
9. Adjust theme on translated pages to include warning that non-English
version may be less accurate.
10. Write/Adjust guidelines for translators, open transifex project
again.
The above might get adjusted, if we'd like to use weblate instead, but I
think that's separate discussion (both in practice require migration to
rst first).
There is also a topic of translating the website itself, which IMO will
become much easier once documentation is moved away.
- --
Best Regards,
Marek Marczykowski-Górecki
Invisible Things Lab
-BEGIN PGP SIGNATURE-
iQEzBAEBCAAdFiEEhrpukzGPukRmQqkK24/THMrX1ywFAmM5uy8ACgkQ24/THMrX
1yySHgf/SPQD43P6rlOVYTQ2ESs8C5i+NKl8VpanV7EOOydXCVwBSe97Liu/Z7xv
haNyGCVSPs3/SYjRMBhMrH5TbL39KSchT4v37DMuy7DeohX5tpS9XC+p/GpecFze
V6gjuEOR47wSxoo6eFYVrn74zn57fCHiOmzms7MrDH0pmUOHlTQVb5qBVlm6SAwm
tIYFmsfAzqeSYn61FgnQ11iNBXSUZVwiG5991BvkZuSkTBe6Y9HT3AJcOwrjDFh3
D79yFE+iDi4qSJHpdvOoARtHQPMXJEn+Ou9xl+g0WGzTusayB/f/2fPkhtruigtb
CLJwWw+jr0+Q5dTdc8kZuVCsENGn7g==
=Do2o
-END PGP SIGNATURE-
--
You received this message because you are subscribed to the Google Groups
"qubes-devel" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to qubes-devel+unsubscr...@googlegroups.com.
To view this discussion on the web visit
https://groups.google.com/d/msgid/qubes-devel/Yzm7MFZFrNbkBS33%40mail-itl.
Re: [qubes-devel] qubes-doc & rtd
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 On Mon, Sep 26, 2022 at 11:33:22PM +0200, mm wrote: > Hi Marek, > > > On 9/26/22 00:01, Marek Marczykowski-Górecki wrote: > > Hi M, > > > > In fact, I'm working on translation-utilz right now too. Marta used her > > google-foo and found this gem: > > https://github.com/SamWilsn/docutils-rst-writer > > > this looks very nice!! :) Thanks Marta! :) > > > So, I replaced most of the qubesrstwriter2.py with just this thing and > > it's almost flawless (especially tables, images etc work out of the > > box). > > OK, thanks for the PR, I'll merge into and get rid of the obsolete stuff > from my branch this days. > > I have some weird customized fixes all over, but this should work. > > One question though: > > have you had success with parsing admin-api.rst (as converted by pandoc from > md?) I think so, yes. > > I get the error when parsing with docutils in order to post-process it for > qubes: > > docutils.utils.SystemMessage: /home/user/testingfilez/admin-api.rst:74: > (SEVERE/4) Unexpected section title IIUC this was issue with overly wrapped table, so '_' or '-' in some cells landed at unfortunate locations and were mis-parsed. In my PR I set line length much longer to avoid this table wrapping and it seems to work. The final sphinx-generated HTML looks a bit weird (no vertical cell borders), but I think that's up to the theme, not RST. > and it cannot get over the table as it is...:/ > > all the best, > > m > > > > > > I massaged the links fixup a bit, and now the only thing it complains > > about is arch-spec-0.3.pdf, and a single "c" lexer issue. That's all. > > Lists starting with non-1 number works too. > > > > I'll push my state in few minutes into separate branch. > > > > BR, > > Marek > > > > > > On Sun, Sep 25, 2022 at 11:31:22PM +0200, mm wrote: > > > Hey Tobias, > > > > > > > I do not know unfortunately what you are referring to? > > > > > I mean the objective is to convert the markdown documentation to rst > > asap > > > > > Unfortunately it did not work out out of the box, due to docutils > > niceties. > > > > > background: I refuse to publish my regular-expressions-monster-convert > > > script. > > > > > I had to write a new one using docutils, as it should be. > > > > > Status as now is: > > > > > there are some minor fixes to be dealt with, such as container for > > > video-tours directive, registering of doc and ref roles > > > > > and a directive for strike through handling, so that the conversion > > can be > > > done with minor headaches by the qubes os team > > > > > (hint: I just pushed master branch on qubes-translation-utilz where the > > > current status can be feared :) ) > > > > > > > Regarding translation as a whole: Michael suggested weblate, as tails > > have > > > experience with it and it seems very nice as OS alternative to > > transifex. > > > Once there are further infos on that will summarize and write. > > > > > Do you mean that or smth else I forget to mention here? > > > > > All the best, > > > m > > > > > On 9/17/22 20:43, Tobias Killer wrote: > > >> Hi, m, > > >> > > >> thank you for all the work! > > >> > > >> As far as I can remember, you talked with Marek about i18n and l10n on > > >> the Qubes OS summit 2022. Could you (or Marek) please give us a summary > > >> of the results of those talks? > > >> > > >> Thank you! > > >> Tobias > > >> > > > > > -- > > > You received this message because you are subscribed to the Google > > Groups "qubes-devel" group. > > > To unsubscribe from this group and stop receiving emails from it, send > > an email to qubes-devel+unsubscr...@googlegroups.com. > > > To view this discussion on the web visit > > > https://groups.google.com/d/msgid/qubes-devel/75e76fab-da0d-058f-c8e9-4db4006c15ed%40maiski.net. > > > > - -- Best Regards, Marek Marczykowski-Górecki Invisible Things Lab -BEGIN PGP SIGNATURE- iQEzBAEBCAAdFiEEhrpukzGPukRmQqkK24/THMrX1ywFAmMyMqwACgkQ24/THMrX 1yxvdQf/edqGoIOTCO+vUWbGhcga0TtFZ3Wusa3nhk0fAzlZeWMcAtnu002UH86R fUwIhlLnpxGBOsbqIOVZV6LKGV86sMSAsxdkrGBil2dzdzcSk7T+c9SerI8JcTDe T2OehXRyelbjUVCVX41gKKR2J5mFfp+5Xo7/QLhaquLC9AIZs+k6WPpcp0C8LIO6 NIrxW5uyDs2u4bf2RJaggH1U6x2RD2qQADAPP9t7DR+5lfUW841ZkPCPBC9NBNbV dShnuSWD2XnTZPfzAhjQiSG+b196Uc8rt/lHUOJYgis7qZ438W/G5ZG/DDu+B1XG SvF1C+1zaDwqUhpWTRZLIG2KvfRzVg== =qAw9 -END PGP SIGNATURE- -- You received this message because you are subscribed to the Google Groups "qubes-devel" group. To unsubscribe from this group and stop receiving emails from it, send an email to qubes-devel+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/qubes-devel/YzIyrHM/M8kP6qEe%40mail-itl.
Re: [qubes-devel] qubes-doc & rtd
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 Hi M, In fact, I'm working on translation-utilz right now too. Marta used her google-foo and found this gem: https://github.com/SamWilsn/docutils-rst-writer So, I replaced most of the qubesrstwriter2.py with just this thing and it's almost flawless (especially tables, images etc work out of the box). I massaged the links fixup a bit, and now the only thing it complains about is arch-spec-0.3.pdf, and a single "c" lexer issue. That's all. Lists starting with non-1 number works too. I'll push my state in few minutes into separate branch. BR, Marek On Sun, Sep 25, 2022 at 11:31:22PM +0200, mm wrote: > Hey Tobias, > > > I do not know unfortunately what you are referring to? > > I mean the objective is to convert the markdown documentation to rst asap > > Unfortunately it did not work out out of the box, due to docutils niceties. > > background: I refuse to publish my regular-expressions-monster-convert > script. > > I had to write a new one using docutils, as it should be. > > Status as now is: > > there are some minor fixes to be dealt with, such as container for > video-tours directive, registering of doc and ref roles > > and a directive for strike through handling, so that the conversion can be > done with minor headaches by the qubes os team > > (hint: I just pushed master branch on qubes-translation-utilz where the > current status can be feared :) ) > > > Regarding translation as a whole: Michael suggested weblate, as tails have > experience with it and it seems very nice as OS alternative to transifex. > Once there are further infos on that will summarize and write. > > Do you mean that or smth else I forget to mention here? > > All the best, > m > > On 9/17/22 20:43, Tobias Killer wrote: > > Hi, m, > > > > thank you for all the work! > > > > As far as I can remember, you talked with Marek about i18n and l10n on > > the Qubes OS summit 2022. Could you (or Marek) please give us a summary > > of the results of those talks? > > > > Thank you! > > Tobias > > > > -- > You received this message because you are subscribed to the Google Groups > "qubes-devel" group. > To unsubscribe from this group and stop receiving emails from it, send an > email to qubes-devel+unsubscr...@googlegroups.com. > To view this discussion on the web visit > https://groups.google.com/d/msgid/qubes-devel/75e76fab-da0d-058f-c8e9-4db4006c15ed%40maiski.net. - -- Best Regards, Marek Marczykowski-Górecki Invisible Things Lab -BEGIN PGP SIGNATURE- iQEzBAEBCAAdFiEEhrpukzGPukRmQqkK24/THMrX1ywFAmMwz8cACgkQ24/THMrX 1yx55gf+L10gTE4rcdKYNE6QVAZQNfpZvuMiCooS19Ik2hy3cAqEnVtDoxSRnuOr jr2NY8vroAEFEoD4U1QPRhOe1HeRL81+9zfTdIVZfKXBCxXSiZMlZuh0LHJYvh5X wE5Skry+ObVjiqA8amb/AeI2Y2LXFAWlV6k0YuwOm5J8/TFu6pe5jKQdaapg5+qa LLtC5tO+g2BcXEhkhFhhvBS/ABJD6vUjWjvdWdQtdnfhPnOgYTKEYXFiNFMPgs8Q 6ClhzILwVghws7frJJ0eOQ8JvbC+OTHAd3KJJZe5M1kAbu6rQIS7XCSOJ222WSSQ NhggXUNW8D1sWkLOWeCgA2QaVReNpQ== =npHQ -END PGP SIGNATURE- -- You received this message because you are subscribed to the Google Groups "qubes-devel" group. To unsubscribe from this group and stop receiving emails from it, send an email to qubes-devel+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/qubes-devel/YzDPx/CP7LOHnLz%2B%40mail-itl.
Re: [qubes-devel] qubes-doc & rtd
o/ or similar. But generally, IMO better have every doc page linked to the main index. > Regarding the old translation markdown workflow - it is still there, and can > be brushed off the dust. > > P.S. I just realized that my .vimrc config was broken. Please excuse the > tabs...! - -- Best Regards, Marek Marczykowski-Górecki Invisible Things Lab -BEGIN PGP SIGNATURE- iQEzBAEBCAAdFiEEhrpukzGPukRmQqkK24/THMrX1ywFAmMV47oACgkQ24/THMrX 1yw1sgf/fW9F3s/Bp1/NmqH4lBH/9jy/p49/lYs8UTU9qWWw8sJY9w6v8rVZ/N3F okWW30Pjw8j1DPx6zY9JWdvzYu9jZAABgHOLNrYY9u4O2WD9V0CFUbZNxezqDyGR rNe8XGdWrWoPDylRW7EYw4BTC6m7RPHK7h3GuyoP0YyTyxDim0+9I4vzgq304uBB NiUJLCdzRaW2x1S5ulJbgSd6iDYdiz2mGuvkaS/hbqv+OnaMkHLaOJmKaLShWY6g Z5dU2tDprpx0ohkXIfd9hTvijrDrb981qDP3pjFY2bXoFFrTaHgUn6myXFCKl5tW F728mHFxzq2LxH1XzCiFeneJ+Qg47Q== =eLlL -END PGP SIGNATURE- -- You received this message because you are subscribed to the Google Groups "qubes-devel" group. To unsubscribe from this group and stop receiving emails from it, send an email to qubes-devel+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/qubes-devel/YxXjuoYSGsH17fUI%40mail-itl.
Re: [qubes-devel] qubes-doc & rtd
structured text (w pandoc f.x.), > which is native for Sphinx, and thus, many of the current rendering issues > should be non-existent. > > One could convert the md to rst as in > > ``` > pandoc doc.md --from markdown --to rst -s -o doc.rst > ``` > > one can view it with restview (pip install restview) > > > ## RTD problems/TODOs > > > 1. Rendering > > There are warnings that have to be adressed such as: > > ``` > /home/user/qubes/qubesos.github.io.testrun/_doc/docs/source/user/advanced-topics/awesomewm.md:22: > WARNING: Pygments lexer name 'shell_session' is not known > /home/user/qubes/qubesos.github.io.testrun/_doc/docs/source/project-security/verifying-signatures.md:150: > WARNING: 'myst' reference target not found: /support/ > /home/user/qubes/qubesos.github.io.testrun/_doc/docs/source/user/troubleshooting/vpn-troubleshooting.md: > WARNING: document isn't included in any toctree > ... > ``` > > 2. Many broken links > 3. PDF - the documentation is not being rendered correctly > 4. EPUB - the documentation is not being rendered correctly > 5. Sphinx uses the Jinja templating engine for its HTML templates. Meaning > for files like > > https://github.com/maiska/qubes-doc.testrun/blob/49253a1f5a24a9a9f5c1c42e2395ca494a1e4b4b/developer/general/style-guide.md > > > this is the result: > https://qubes-doctestrun.readthedocs.io/de/latest/developer/general/style-guide.html > > > I have not found a converter from liquid to jinja, so there should be > another solution > > 6. External files: can be just listed in the doc.md and the markdown files > can be deleted. But the redirects are to be handled > 7. Warning: RTD is somewhat buggy if one pushes immediately one after > another several branches for one project that are activated > 8. Find out how to handle multiple translations with one repo in RTD > 9. Uploading to transifex problem (wip) > 10. Analytics (JS in general in RTD): script as in [14] with a RTD section > regarding this [15] > > > What are your thoughts on this? Let me try to resurrect this thread :) First of all, thanks again for all this analysis. I think indeed RTD is the way to go. We'll have occasion to talk about details on the upcoming Qubes summit. Personally, I wouldn't exclude an option to convert documentation to ReST format, especially since we get several more features then (better internal links tracking, PDF/ePUB generation, built-in macros for notices, warnings etc, and several more). But of course this needs to be weighted against other factors like complexity of the conversion itself, or ease of use for maintainers and contributors. See you soon! > All the best, > > m > > [1] https://github.com/ultrabug/mkdocs-static-i18n > [2] https://github.com/mondeja/mkdocs-mdpo-plugin > [3] https://docs.readthedocs.io/en/stable/localization.html > [4] https://myst-parser.readthedocs.io/en/latest/ > [5] https://www.sphinx-doc.org/en/master/usage/markdown.html > [6] https://myst-parser.readthedocs.io/en/latest/sphinx/intro.html > [7] https://myst-parser.readthedocs.io/en/latest/sphinx/reference.html > [8] https://www.sphinx-doc.org/en/master/usage/theming.html#builtin-themes > [9] https://www.sphinx-doc.org/en/master/usage/theming.html > [10] https://sphinx-rtd-theme.readthedocs.io/en/stable/configuring.html > [11] https://sphinx-themes.org/#themes > [12] https://docs.readthedocs.io/en/stable/guides/adding-custom-css.html > [13] https://github.com/sphinx-doc/sphinx-doc-translations > [14] > https://assets.readthedocs.org/static/javascript/readthedocs-analytics.js > [15] > https://docs.readthedocs.io/en/latest/advertising/advertising-details.html#analytics > > -- > You received this message because you are subscribed to the Google Groups > "qubes-devel" group. > To unsubscribe from this group and stop receiving emails from it, send an > email to qubes-devel+unsubscr...@googlegroups.com. > To view this discussion on the web visit > https://groups.google.com/d/msgid/qubes-devel/f24cb2b0-9465-ef3c-c71f-afb71248ab9f%40maiski.net. - -- Best Regards, Marek Marczykowski-Górecki Invisible Things Lab -BEGIN PGP SIGNATURE- iQEzBAEBCAAdFiEEhrpukzGPukRmQqkK24/THMrX1ywFAmMSIcwACgkQ24/THMrX 1yw03Qf/c63FuOGz6zsBwRWMLabRM3JxCA05ILFu76bg3/MI68DtbiRcYEBnCekR CbvNIxTLq077X4N58HiIlsunhrln+n2eLgsD6H/ljp3ZGmbNdzfZhz2WdbWMaKjK 4dzdxEb6pUfrDqXrNOrxDOxRHBJYLR6mjr2ih211iPVaJccgIny8l8zSkWpTmG6S JmowbLeaxfNXsv00yODQ9Hv/7hTZj5xd0Kntq17FGrL9BWLFad0fVYxzZ93Dh6NI g6KgSnwWAvLqUZjQ7BSrjhbXuKUOeIHJ+luA23aqKioWHNcA9SXvtz2bUZyYVNeM Eve3568YYj12PcZIjbZH+3leDZ+EbA== =kYM7 -END PGP SIGNATURE- -- You received this message because you are subscribed to the Google Groups "qubes-devel" group. To unsubscribe from this group and stop receiving emails from it, send an email to qubes-devel+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/qubes-devel/YxIhzCN82osQq9VK%40mail-itl.
Re: [qubes-devel] Security concerns with split-gpg1 to split-gpg2 migration
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 On Tue, Jul 19, 2022 at 07:40:00PM -0400, Demi Marie Obenour wrote: > On Wed, Jul 13, 2022 at 03:35:46PM +0200, Marek Marczykowski-Górecki wrote: > > This indeed makes migration easier, and is exactly the thing we should > > recommend. I think we should adjust defaults to make the scenario > > described earlier unlikely to happen by mistake. > > > > What about something like this: > > 1. Make default gpg homedir for split-gpg2 backend something else than > > ~/.gnupg. > > 2. In the migration guide include step to generate subkey for signing > > (the one for encryption should be already there). > > 3. In the migration guide include step like: > > gpg --export-secret-subkeys | gpg --homedir /default/split-gpg2/gpghome > > --import > > 4. Maybe even consider an option (default enabled, but possible to > > disable) that does the step 3 automatically. Either if the split-gpg2 > > homedir doesn't exist or if secret keys in the default keyring are newer > > than in split-gpg2's. > > > > I'm not sure about the last point - it may make key management a bit > > easier (for example for those preferring to create new subkeys instead > > of extending expiration of existing ones). But on the other hand, one > > still need to move public part around(*), so it doesn't eliminate all the > > manual steps... > > Moving the public part around can be semi-automated, as you suggest. > Generating the subkey is also easy if the key is stored in software, and > it might even be possible to write a script to do it. > > The main problem is smart card support. OpenPGP smart cards typically > have three key slots: one for signing, one for decryption, and the third > for authentication (often SSH). If all three slots are in use, it will > not be possible to generate or use the subkey on the card. Generating > the key in software would work, but it loses the advantages of the smart > card. That's a valid point. But also, if you have a smart card, you have already more or less the functionality of split-gpg2 there. The main difference being a confirmation prompt, but some security keys provide this too. So, there is little (not zero, but little) point in combining split-gpg2 with a smart card. And also, you can avoid the issue discussed here the very same way - by having separate card with just subkey(s) - instead of just separate homedirs. In short - I wouldn't worry about slots availability too much. It is something we should probably document in the migration guide, together with workarounds (separate offline storage/card for the primary key, or software storage for some subkey). If many users will be affected by this limitation (and unable/unwilling to use workaround), we may consider some alternative solution. But I kind of suspect it won't be necessary. > To work around this problem, I think we could provide a split-gpg1 > variant that only supports a subset of safe operations. > --list-keys, --list-secret-keys, --export, and --sign (with hex UIDs) > should be safe. --encrypt should also be safe, but it is not very > useful without the (unwanted) --import. That said, these operations > should enough for Thunderbird, which does encryption internally. > Decryption can be handled via split-gpg2, with filtering to prevent > attempts to decrypt with a signing key. Attempts to perform operations > that the split-gpg1 subset does not allow would be handled via > split-gpg2, by exec’ing GnuPG directly with the appropriate sockets set > up. "should enough for Thunderbird" - that's exactly the thinking that got us to the current situation with split-gpg1. Even if a static set of options will be enough for all the future versions of TB (which I highly doubt), there are other applications that users expect to work too. Note the main issue about options filtering is not about the main command options, but all the auxiliary options. > > (*) Maybe split-gpg2 should include a separate qrexec service that just > > exports all the public keys from the backend? It could save the user one > > qvm-copy call... > > It absolutely should for multiple reasons, not least of which being that > it allows for easily maintaining a shared public keyring. One can > maintain a shared collection of public keys in one qube, and other qubes > can import keys from it as needed. - -- Best Regards, Marek Marczykowski-Górecki Invisible Things Lab -BEGIN PGP SIGNATURE- iQEzBAEBCAAdFiEEhrpukzGPukRmQqkK24/THMrX1ywFAmLXW6EACgkQ24/THMrX 1ywX+wf/YOC9+ITgbycY3ebCBuH00Pwe1tr13Bs/rxe1eNClwRnBSCdPpSKbYwcQ 2plQXFE7woIqw25diVYCWKnjAc6kQJdhpVCCkTrCOwntKSg/+54YmPXMzXr6Q3SJ p5uAvU9ej4RvQ+FZnviEQvIFEM5OmEFizabRssEwGrD7R8N5C6pvrRnbVBngMbCF I9XzVEo4PlgE/+lbm+erSm5A
Re: [qubes-devel] Security concerns with split-gpg1 to split-gpg2 migration
y this scenario, see the > --export-secret-subkeys option. > > From the manpage: > > --export-secret-keys > --export-secret-subkeys > [...] > > The second form of the command has the special property to > render the secret part of the primary key useless; this is a GNU > extension to OpenPGP and other implementations can not be > expected to successfully import such a key. Its intended use is > in generating a full key with an additional signing subkey on a > dedicated machine. This command then exports the key without the > primary key to the main machine. This indeed makes migration easier, and is exactly the thing we should recommend. I think we should adjust defaults to make the scenario described earlier unlikely to happen by mistake. What about something like this: 1. Make default gpg homedir for split-gpg2 backend something else than ~/.gnupg. 2. In the migration guide include step to generate subkey for signing (the one for encryption should be already there). 3. In the migration guide include step like: gpg --export-secret-subkeys | gpg --homedir /default/split-gpg2/gpghome --import 4. Maybe even consider an option (default enabled, but possible to disable) that does the step 3 automatically. Either if the split-gpg2 homedir doesn't exist or if secret keys in the default keyring are newer than in split-gpg2's. I'm not sure about the last point - it may make key management a bit easier (for example for those preferring to create new subkeys instead of extending expiration of existing ones). But on the other hand, one still need to move public part around(*), so it doesn't eliminate all the manual steps... (*) Maybe split-gpg2 should include a separate qrexec service that just exports all the public keys from the backend? It could save the user one qvm-copy call... - -- Best Regards, Marek Marczykowski-Górecki Invisible Things Lab -BEGIN PGP SIGNATURE- iQEzBAEBCAAdFiEEhrpukzGPukRmQqkK24/THMrX1ywFAmLOyjIACgkQ24/THMrX 1ywntwf9Fh6CObD3ZZRFWm08bkXJYld8C4oap2FqVJ2UuHJfO8GG1LWC+l8TDeCi duXaHxHK/BfCdxhiMDxrpPL63wam64s56PFjSalr51ranEyCLlm+GF3Qgp7PE+av xgblUBg9IqbqOGyFrcWELa9667OxS5Uq5JTmiisNJfwToBRBVgSfw0rzxcbNpErU Nej/dO7eCrw0YL9L7unbvyLj/Gk6Z833Tn446wfa0UAd2TK1oB5tvcoF9umLleCn pXN+RJuoKDYgatsF4txh3+OO8qufn/wPyUmnspFMeOJ+x3NjpUSt+GaTyKdljaBm pEH3M1mvvmTj2QhRcuHitAtLnACq+Q== =28dJ -END PGP SIGNATURE- -- You received this message because you are subscribed to the Google Groups "qubes-devel" group. To unsubscribe from this group and stop receiving emails from it, send an email to qubes-devel+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/qubes-devel/Ys7KMlhEYz9e3CFx%40mail-itl.
Re: [qubes-devel] Write access to standalone's Lv
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 On Thu, May 26, 2022 at 08:36:29AM -0700, Pin dev wrote: > Hello, after an update I don't have qubes-core-agent anymore on a Debian > standalone VM. > However, I did not set a password to the user "user" and root account is > disabled, so I cannot login anymore. > I tried to losetup loop43 /dev/qubes_dom0/vm-dev-root but it appears to be > busy. > After that, I tried to mount /dev/qubes_dom0/vm-dev-root /mnt but it says > wrong fs type. > > Is there any chance I could get back write access to that private volume? Take a look at this doc: https://www.qubes-os.org/doc/mount-lvm-image/ But also, if you haven't restarted that template too many times, you may be able to revert the last update: https://www.qubes-os.org/doc/volume-backup-revert/ - -- Best Regards, Marek Marczykowski-Górecki Invisible Things Lab -BEGIN PGP SIGNATURE- iQEzBAEBCAAdFiEEhrpukzGPukRmQqkK24/THMrX1ywFAmKPrWUACgkQ24/THMrX 1yyXsgf/ang8jKCUVKvM8y5Y0VZykp8T4V5ur7S+PAzYRqozefZkbe8HlAEL2el7 yWGlX+bHvb640O3bNZA/BZiQ9NnkJV1hpcbHBFSo1buKTWc37bDGGvfawLZl0bhe weLlU9+uLoR2J/s38b5awDQshGeQN8Af3Y5v8Eb9rd3Cmi/Y0c3n12Qmxn2DPnHw irIzHBf5vHMNYN5HSALcPA/RpOXcvZsG8lmfbVhe2UKnmrrZlYeNuj7x9FobcOtK 1s42h60kyuuvuFOyqlJsZU0hn2NmERxqZn3wkL/xSwMDRiy9hKXxT8T7nI+4cTP8 fStkhMrmDOzDD4LiW1eqn5uRwaB1Gw== =3u48 -END PGP SIGNATURE- -- You received this message because you are subscribed to the Google Groups "qubes-devel" group. To unsubscribe from this group and stop receiving emails from it, send an email to qubes-devel+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/qubes-devel/Yo%2BtZsed8Szk4s%2BT%40mail-itl.
Re: [qubes-devel] GitHub ticket #5929 disappeared (official Arch Linux template)
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256
On Wed, Apr 20, 2022 at 12:32:56PM +, Rusty Bird wrote:
> Marek Marczykowski-Górecki:
> > On Mon, May 10, 2021 at 11:56:51AM +, Rusty Bird wrote:
> > > Marek Marczykowski-Górecki:
> > > > On Mon, May 10, 2021 at 10:27:38AM +, Rusty Bird wrote:
> > > > > I was trying to check on the status of the Arch Linux template, but
> > > > > the issue ticket[1] has disappeared ("Page not found"). Maybe it's
> > > > > caught in a GitHub spam filter?
> > > >
> > > > Likely yes, for some weird reason. I've asked github support to restore
> > > > it.
> > >
> > > After a couple of GitHub API requests, it looks like they're currently
> > > memory-holing 43 issues:
> >
> > Thanks for the list. Based on it, I've searched the github export I do
> > from time to time, and I can confirm most of them are not spam (at least
> > looking at the title, haven't checked the body).
> > Specifically this list:
> > https://github.com/QubesOS/qubes-issues/issues/1004
> > https://github.com/QubesOS/qubes-issues/issues/1017
> > https://github.com/QubesOS/qubes-issues/issues/1025
> > https://github.com/QubesOS/qubes-issues/issues/1127
> > https://github.com/QubesOS/qubes-issues/issues/1510
> > https://github.com/QubesOS/qubes-issues/issues/1678
> > https://github.com/QubesOS/qubes-issues/issues/1794
> > https://github.com/QubesOS/qubes-issues/issues/2196
> > https://github.com/QubesOS/qubes-issues/issues/2221
> > https://github.com/QubesOS/qubes-issues/issues/2669
> > https://github.com/QubesOS/qubes-issues/issues/2804
> > https://github.com/QubesOS/qubes-issues/issues/2862
> > https://github.com/QubesOS/qubes-issues/issues/3119
> > https://github.com/QubesOS/qubes-issues/issues/3272
> > https://github.com/QubesOS/qubes-issues/issues/3358
> > https://github.com/QubesOS/qubes-issues/issues/3395
> > https://github.com/QubesOS/qubes-issues/issues/3402
> > https://github.com/QubesOS/qubes-issues/issues/3414
> > https://github.com/QubesOS/qubes-issues/issues/4037
> > https://github.com/QubesOS/qubes-issues/issues/4056
> > https://github.com/QubesOS/qubes-issues/issues/4107
> > https://github.com/QubesOS/qubes-issues/issues/4108
> > https://github.com/QubesOS/qubes-issues/issues/4240
> > https://github.com/QubesOS/qubes-issues/issues/4605
> > https://github.com/QubesOS/qubes-issues/issues/4690
> > https://github.com/QubesOS/qubes-issues/issues/5033
> > https://github.com/QubesOS/qubes-issues/issues/5083
> > https://github.com/QubesOS/qubes-issues/issues/5154
> > https://github.com/QubesOS/qubes-issues/issues/5204
> > https://github.com/QubesOS/qubes-issues/issues/5205
> > https://github.com/QubesOS/qubes-issues/issues/5325
> > https://github.com/QubesOS/qubes-issues/issues/5334
> > https://github.com/QubesOS/qubes-issues/issues/5582
> > https://github.com/QubesOS/qubes-issues/issues/5928
> > https://github.com/QubesOS/qubes-issues/issues/5929
> > https://github.com/QubesOS/qubes-issues/issues/6415
> > https://github.com/QubesOS/qubes-issues/issues/6422 (dupplicate of 6415)
> > https://github.com/QubesOS/qubes-issues/issues/6451
> > https://github.com/QubesOS/qubes-issues/issues/6452 (dupplicate of 6451)
> >
> > That said, many of them are misplaced and were immediately closed as
> > "invalid" as they should be rather posted to forum or ML.
> >
> > I'll add them to the list in github support request...
>
> Did you ever hear back from them?
Yes, a month later, and it's not very optimistic one:
It appears that these issues are currently hidden for reasons relating
to the accounts that opened them.
I'm unable to provide any further information about this for privacy and
security reasons however if the account holders reach out to us we may
be able to assist them directly.
Unfortunately we're unable to re-show these issues until such times as
we can work with those account holders.
Sorry it's perhaps not the news you were hoping for but please let me
know if you have any other questions.
> I just read something disturbing that might be relevant:
>
> | Apparently, “suspending an account” on GitHub actually means *deleting
> | all activity for a user* — which results in (1) every pull request
> | from the suspended account being *deleted*, (2) every issue opened by
> | the suspended account being *deleted*, (3) every comment or discussion
> | from the suspended account being *deleted*. In effect, the user’s
> | entire activity and history is evaporated.
>
> | All
Re: [qubes-devel] systemd rescue mode vs qubes root account locked
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 On Tue, Feb 08, 2022 at 12:13:20AM +, Holger Levsen wrote: > hi, > > recently I had some hw issues which I needed to debug so I tried > booting with systemd rescue mode (by appending systemd.unit=rescue.target > to the kernel cmdline) but that failed because the root account is locked > on Qubes. > > So I'm wondering what is the recommended resuce mode for Qubes? booting > the installer in rescue mode or setting a root password or??? Generally, booting the installer is more reliable in some cases, since it doesn't rely on dom0 being in any usable state. But since that may be inconvenient at times, you can get shell in initramfs using 'rd.break' on the kernel cmdline. Or, if you just want to avoid staring any VM, use 'qubes.skip_autostart' option. - -- Best Regards, Marek Marczykowski-Górecki Invisible Things Lab -BEGIN PGP SIGNATURE- iQEzBAEBCAAdFiEEhrpukzGPukRmQqkK24/THMrX1ywFAmIB1XAACgkQ24/THMrX 1yyvdQf7B5DOOpr+BcEJv1l2rUPyXHEmbpNm/ird6SnTpyqso9ljwQq7NsQBLCcH JpWnllx1FWgzHtikhOojHXIhvUesRyWBbzmo+k6c2N6WK8Bbym7FbcdtkbIDEMHO fTXhR+Osr6cAfoQJUiyp0wfG5hzFUAM1mDTi8vlXEcNa02zEH7IQqsLAhO8Zl30z 3X6qTx+3v5aLxqCI3ZaD2TEBnGWzOowZutGSsAtgA5lGtflwmQeaBglVmXYLbbLX iKu1pvWLDA8dr8+mYu0xaAFTAVoNn9DfTfD1An/YHMtLATmEdQF3v0rdtpbohA2N HBsmOAjkPP8HyjQ4981ngcXqeQ5gIQ== =uemw -END PGP SIGNATURE- -- You received this message because you are subscribed to the Google Groups "qubes-devel" group. To unsubscribe from this group and stop receiving emails from it, send an email to qubes-devel+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/qubes-devel/YgHVcAqrEtbZcCVN%40mail-itl.
[qubes-devel] There will be 4.1.0-rc4
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 Hi all, Just letting you know that there will be 4.1 rc4, because of few bugs in the stubdomain / gui-agent there, which are rather severe (including GUI for Windows VMs crashing). Specifically those two: https://github.com/QubesOS/qubes-issues/issues/7148 https://github.com/QubesOS/qubes-issues/issues/7164 There are few other issues that we will fix, while at it. I'll update the schedule shortly. - -- Best Regards, Marek Marczykowski-Górecki Invisible Things Lab -BEGIN PGP SIGNATURE- iQEzBAEBCAAdFiEEhrpukzGPukRmQqkK24/THMrX1ywFAmHWbIEACgkQ24/THMrX 1yweXAf+OkeFqk3szYIp5MS9unNDbH1A4IJJlMx7aCUIvmfotJG53lOjA7gKQsvK H0EIO+MRA5udD88Hfza+wYJNYGrnx8UMzbpak+mOegscIz11He4NGXRgkWbXZt4X PAK3PCi5HXP+D1vept2JeSW6on+9d2m27q+1NuBUp2Ekii0KvsGxqV/RCYobz+B6 JpCIu6LtPWuhK0gqfyxa7GRA+I7Mg5aip/Bwbqq/z3/bGsMMi1cD0Cl8XFTbGYn7 xTksecDJKNzZ8Oi+/Efh3EUgAxgOa4hm0l7dujurRswAb97tL+vcJWUDlKfsijpW YQ4/uMEJ4EHzqY4Hrs5De0C/pkslDw== =fvfA -END PGP SIGNATURE- -- You received this message because you are subscribed to the Google Groups "qubes-devel" group. To unsubscribe from this group and stop receiving emails from it, send an email to qubes-devel+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/qubes-devel/YdZsgqPyyD%2B4PCLr%40mail-itl.
Re: [qubes-devel] Contributing to hardening AppVMs templates
t; feasible to create a file system accessible by both Dom0 and the AppVM where > AppVMs can transfer the files to be manipulated and then execute those actions > from Dom0, not only the confirmation step. No, that's backward. Filesystem-level sharing is rather complex thing, with a huge attack surface, we definitely don't want to expose dom0 to such attacks. When you design your data flow, you (currently, unfortunately) need to think how do you trust components involved. Making transfer trusted->untrusted->trusted slightly(*) less risky is not very useful. If you need such transfer (assuming here you trust the "original" content of downloaded data), simply use appropriate VM to download the file. If in doubt, use (fresh) disposable one. If you don't trust the original content, there are still few things you can do: - for pdf and images, we have tool to "clean" them up[9] - for others, you can always open them in disposable qube, including extracting the data you actually need there (in your very example - open such tar in a disposable qube, and qvm-copy only the content you need - and still treat it as untrusted) (*) Your solution is only about ensuring the file that is sent is the one that got written. But does not cover several other parts: - is correct data actually written (substitute file at download stage, instead of qvm-copy) - is the tool used to preview the file actually showing you really the right content (substitute file at preview stage) and probably few more. > Would anyone kindly give me some hint about were I can start to achieve > this? You can start by checking https://www.qubes-os.org/doc/contributing/. Things like wrapping Firefox (and possibly others) with firejail sounds like a good idea for the start. To keep things nicely organized, IMO it should be a separate repository (and separate rpm/deb/... package). You can use for example https://github.com/QubesOS/qubes-app-linux-snapd-helper as a skeleton. BTW, your appendix A is rather complex, there are much simpler ways. Hint: qvm-run --localcmd. The lack of network in dom0 (and templates) have two purposes: 1. Make it harder to get _into_ dom0. 2. Avoid _accidental_ untrusted data download (like, your favorite desktop configuring tool trying to download you a wallpaper from http://some.random.website/). If you are in dom0 already, your options are rather limitless. Breaking naive connect-back shells is rather poor consolation. [1] https://github.com/QubesOS/qubes-issues/issues/4239 [2] https://github.com/QubesOS/qubes-issues/issues/4088 [3] https://github.com/orgs/QubesOS/projects/5 [4] https://www.qubes-os.org/faq/#what-is-qubes-attitude-toward-changing-guest-distros [5] https://github.com/QubesOS/qubes-issues/issues/6877 [6] https://github.com/QubesOS/qubes-issues/issues/6366#issuecomment-767635670 [7] https://github.com/QubesOS/qubes-issues/issues/7130 [8] https://www.qubes-os.org/news/2020/03/18/gui-domain/ [9] http://blog.invisiblethings.org/2013/02/21/converting-untrusted-pdfs-into-trusted.html - -- Best Regards, Marek Marczykowski-Górecki Invisible Things Lab -BEGIN PGP SIGNATURE- iQEzBAEBCAAdFiEEhrpukzGPukRmQqkK24/THMrX1ywFAmG8B84ACgkQ24/THMrX 1yxjiAf8Day2jC1Mq6i6WVsvUUPe2m3q0e/StY+5QJDSRk7k0RLx9XZYgd85S0NP +eCq7WtRo0KCBidVm8rIl20f3cPzTdORNM2MwaSqcMqy3562NzEXbNJT3mj3lb4O euf1ICMFY+AGnq0SvIkNAszFG0WljfjcxlQpVeHT112hct8hsFhwgFdngbvI/Ueq pFsdHnDFTBbmvkA/x4AjmP+urE5E+z9ZM1KsAuUQx53q/9uXK+vW1IZeiIHGA9Cl jqDsSDAN0YTNii4FldQFBGLlVSUTJcojbM4bW2TtOOLZUDKX21FdcVooB7sARZXz zhzyjWjvUUSKahSiC8nXjo6/lXy0yg== =uvJs -END PGP SIGNATURE- -- You received this message because you are subscribed to the Google Groups "qubes-devel" group. To unsubscribe from this group and stop receiving emails from it, send an email to qubes-devel+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/qubes-devel/YbwHzsdq0wRpEced%40mail-itl.
Re: [qubes-devel] Design questions for the next steps of the Qubes shared folders service
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 On Thu, Dec 16, 2021 at 01:27:43AM +0100, Manuel Amador (Rudd-O) wrote: > On 16/12/2021 01.07, Marek Marczykowski-Górecki wrote: > > Here is how qrexec policy prompt is doing it: > > https://github.com/QubesOS/qubes-core-qrexec/blob/master/qrexec/tools/qrexec_policy_exec.py#L64-L112 > > Bad news, I did not understand any of that code. :-( > > Just to see if I understand at least the process: > > 1. dom0 sends RPC `policy.Ask` to GUIVM > 2. this policy program pops up a dialog > 3. the response comes back Yes, exactly. > If this is correct, please let me know if my following theory is correct: > > 1. I create a `policy.AskBlah` policy with the same config as `policy.Ask` Since it's dom0 who make the "policy prompt" call, you don't need a policy for it. > 2. I move my program that asks via UI to the package to be installed in >the GUIVM Yes. > 3. I also move my RPC service code to that package You mean the ruddo.AuthorizeFolderAccess service? No, that stays in dom0. > 4. I make my dom0 RPC that (today) executes the GUI program, invoke the >policy.AskBlah service, and await a response Yes. > If so, how do I distinguish between the case of GUIVM and no GUIVM? You check for the source domains's "guivm" property. If it's "dom0", you call `/etc/qubes-rpc/policy.AskBlah` directly, otherwise you call it via qvm-run. > Additionally, what about the folder share manager application? It currently > runs in dom0 (kinda has to, because dom0 is where the file share policy is > stored). Yes, I guess it should remain in dom0 in this design. - -- Best Regards, Marek Marczykowski-Górecki Invisible Things Lab -BEGIN PGP SIGNATURE- iQEzBAEBCAAdFiEEhrpukzGPukRmQqkK24/THMrX1ywFAmG6ir8ACgkQ24/THMrX 1yzVWQf/Q9To2pFR5hATlzRGzYjXyhSVvzG+P0joXitkc+rbZ7T6gAlwkwRqNm2L ZQzxQgkAlUZ+xOvGv2w1nE+sxwHd5c5cvAe8WKnIA6oiEUnfN+y5MDuK7iBCUMGB ZAtkcVynomXYiNhLwUw+4EYuNKSeWMcVWH18RhChVp99XXfkr3kWlzjofGe1VCNK +660MsfMlmw3whZegzpQ7sYFfF1TGSoojKKUwrrSmWEoImR0YPpabmOwQGWV0rQl KYmQOUYuYmQiBx8T/J+bCp5YnOAfJnGIUw1AHMgKbubSQN6lqnMHwOgHXoWOo9mv f5NMsiLv9SLrRMarFLsC/TobHB7RJA== =C9IM -END PGP SIGNATURE- -- You received this message because you are subscribed to the Google Groups "qubes-devel" group. To unsubscribe from this group and stop receiving emails from it, send an email to qubes-devel+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/qubes-devel/YbqKwH6Dd0ZgMdlU%40mail-itl.
Re: [qubes-devel] Design questions for the next steps of the Qubes shared folders service
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 On Thu, Dec 16, 2021 at 12:17:44AM +0100, Manuel Amador (Rudd-O) wrote: > Prefacing this response with: > > I went with the implementation as designed by the document. In the future I > will revise argument passing to use the new 4.1 style, instead of base64 > over pipes. Currently the implementation uses a custom-made dialog — a very > nice one, if I do say so myself — in the spirit of the feature request > #5853. :) > On 14/12/2021 15.28, Marek Marczykowski-Górecki wrote: > > I think it looks ok. Regarding one-time access, I'd rather specify it > > with a timeout, to avoid cases when the client VM requests authorization but > > uses it much later. > > This will land in the project's to-do list and will be implemented at some > point in the future. Patches always welcome! > > > > > One thing you may want to consider is interaction with GUI domain - in > > this case dom0 couldn't directly ask the user, but rather ask the GUI > > domain to display the prompt. We do this for normal policy prompts. > > Anyway, it's of course up to you whether you support GUI domain or > > not... > > Yes, I intend to support the GUI domain. *How do I do this?* Right now my > code merely spawns up, from dom0, a GUI dialog using DISPLAY:=0. This was > lifted from other parts of the Qubes repositories. If going with standard qrexec prompt (+#5853), you'd get that for free ;) Otherwise, you need a qrexec service that calls into GUI domain to do the prompt (and then validate its output to really allow only the thing that was asked about, not something else). Basically, factor out the prompt code into separate file, then call it via `qvm-run --service ...` instead of directly. Here is how qrexec policy prompt is doing it: https://github.com/QubesOS/qubes-core-qrexec/blob/master/qrexec/tools/qrexec_policy_exec.py#L64-L112 - -- Best Regards, Marek Marczykowski-Górecki Invisible Things Lab -BEGIN PGP SIGNATURE- iQEzBAEBCAAdFiEEhrpukzGPukRmQqkK24/THMrX1ywFAmG6g08ACgkQ24/THMrX 1yyy/wf+MP+ZLD3cgBPZivLwOaIyZGWn6I/nmaCEQnmjv6xnUw/gp37fEJIaDn1p olyP4egGDSb0pDgf9F2JUfPNX9iO59AUdmxkq7tuQWNzP/Hp8vtcFR3vzS4Sug9H TCW40s4KR3YMRR/I2icTe8KvuCqYrt7gE2WEFxuQ256OJtUM5VTfHZaEX4iy6MU9 P568+i34F7IEmj4p9ZvYAQBDgZXiuFCDi5Xo37Ma5U9kG8SQEwiPS9q5PTNkF065 N3sQqW+J1XDAIZRa2fAGnKcRwAFFm9Xdnap3JhaoiWlk5CaSJLWinLD/qH9WEbo7 /swlVqBnPt0uc/tWjuOi1UAt4dw7Ew== =yfj2 -END PGP SIGNATURE- -- You received this message because you are subscribed to the Google Groups "qubes-devel" group. To unsubscribe from this group and stop receiving emails from it, send an email to qubes-devel+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/qubes-devel/YbqDTxMnZI5DINZi%40mail-itl.
Re: [qubes-devel] Design questions for the next steps of the Qubes shared folders service
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 On Mon, Dec 13, 2021 at 06:58:02AM +0100, Manuel Amador (Rudd-O) wrote: > Hi folks. > > I wrote the Qubes shared folders service in an afternoon. It is what it is > -- useful, but not ideal. > > I've come up with a design for an improved version that I would like you to > review for correctness and to see if it could be implemented better. I > think this design has potential, and I want your feedback before > implementing it. > > The document is at > https://github.com/Rudd-O/qubes-shared-folders/blob/master/doc/authorization-design.md > — I am adding the contents of the document below. Please go ahead and > analyze it. Thanks in advance for your feedback. > # User interaction > > What we propose is the following: > > 1. The user instructs the client qube to mount folder `X` on the server > qube. > 2. dom0 asks the user "client qube wants to mount folder `X` on server > qube". > 3. The user responds accordingly. If authorized, the connection is > permitted and the client qube can successfully mount `X`. > > The Qubes policy argument mechanism is insufficient for the proposed > interaction. For one, it limits the argument size to 64 bytes This is no longer the case in Qubes 4.1: https://www.qubes-os.org/news/2020/06/22/new-qrexec-policy-system/#performance-improvements (the limit is now ~64k) > , making it > unsuitable for a wide possibility of paths the user might want to connect > to. Second, it doesn't actually convey the information that the client qube > sent — it conveys a form of hobbled information that crucially does not > include spaces, slashes, or other special characters, all of which are > legitimate in POSIX paths. There are ways around it - encode the path. We do that for qubes.VMExec service for example: https://www.qubes-os.org/doc/vm-interface/#qubes-rpc This way, the argument itself is still safe to process in various tools (even log4j :P), and represents almost friendly path - /home/user/Work/project-X would become -2Fhome-2Fuser-2FWork-2Fproject--X. > Third, the way that the question is presented is > not exactly usable. This is indeed a problem, especially the user would see only a mangled path, and no info that the thing is indeed the path... This could be solved with https://github.com/QubesOS/qubes-issues/issues/5853, but that exists only in plans now. > # Implementation details > > The circumstances lead us to consider the implementation of an alternative > security mechanism, proposed here. (...) I think it looks ok. Regarding one-time access, I'd rather specify it with a timeout, to avoid cases when the client VM requests authorization but uses it much later. One thing you may want to consider is interaction with GUI domain - in this case dom0 couldn't directly ask the user, but rather ask the GUI domain to display the prompt. We do this for normal policy prompts. Anyway, it's of course up to you whether you support GUI domain or not... - -- Best Regards, Marek Marczykowski-Górecki Invisible Things Lab -BEGIN PGP SIGNATURE- iQEzBAEBCAAdFiEEhrpukzGPukRmQqkK24/THMrX1ywFAmG4qfIACgkQ24/THMrX 1yy3Ywf7BE7xOcqzMdSgn4Un3SZkokDMBaoN0Rr2EQ5pNLPgM9SUI9NEnvJ+TEZ7 xLTvNpRiYWSkjmVXsfUJrCZmQ+0NEvifiay4xWP0g/paYfRaL9Pa2vMOtHMv2Ncv vcE0T01bCrek/0BPJfsQI1n27zaZdUwIz4o3sJofzRoocMBk7Kq0x6jC/Gw35Qkh xi42R7XcDutPwuRi5JZKTBxfH7hVIKkizEIEUsN7qe0Fn80nfhRvdIi6VgJb+Wz2 3cJ38oiMBQg46OQ256J1viMZaKz+H4hyDWtTJcCzLcu9mImr+tkdIVHTFrBNMjbF QRmSGRsAV3LuScjUGCTIYDAV3A6qmA== =OcxO -END PGP SIGNATURE- -- You received this message because you are subscribed to the Google Groups "qubes-devel" group. To unsubscribe from this group and stop receiving emails from it, send an email to qubes-devel+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/qubes-devel/Ybip8vY29iVo3cY4%40mail-itl.
Re: [qubes-devel] qubes-updates-proxy in dvm
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 On Wed, Nov 17, 2021 at 08:00:37PM +, Zrubi wrote: > On 11/17/21 19:48, Marek Marczykowski-Górecki wrote: > > > > the folder name has a typo: > > > qubes-udates-proxy vs. qubes-updates-proxy > > > > > creating the correct directory fix the issue. > > > Now the question is who (or what process) creating that wrongly? > > > > You, when adding it to qvm-service :P > > Ahhh. > > a 'nice' debug session to find my own typo. :| > > And the empty service list in the GUI is the expected behavior? - would > have saved the world from this thread ;) Theoretically there should be a drop-down list with known-supported services, but _this_ seems to be broken for disposable qubes... - -- Best Regards, Marek Marczykowski-Górecki Invisible Things Lab -BEGIN PGP SIGNATURE- iQEzBAEBCAAdFiEEhrpukzGPukRmQqkK24/THMrX1ywFAmGVZ9YACgkQ24/THMrX 1yyUGgf+KGfv/Mp+0en1/igOQ9EDG41qEuHph7dCBujByowDs4ATM5QQK8MBSpL4 67t6ZNBj5xA71FugWeiS9EQqz6zkJ9s1ntPfcCMaqMQspueSUQ6zoal6MHldSDBv VOrtOBeNCjJGOkOibgDGEL4DqlxFlxsdExTzVnUwp2TghEeLYCa6ywvDhtcIwfDk /HJj/aFMGualkEkr+6/ldjwJBh7NihLFSL0cQGNKlYUjhWzo49+3AS+42bxxWWCR DH6pG+sb2m3pYi79ieM5rNWwycdfI3LCIuGCplHJA0DQBKzDhinRsPO5xWwZE2Pw TZo1AN7owpqul0IdPHmIdN8e7hlM5w== =ELIn -END PGP SIGNATURE- -- You received this message because you are subscribed to the Google Groups "qubes-devel" group. To unsubscribe from this group and stop receiving emails from it, send an email to qubes-devel+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/qubes-devel/YZVn1odZuHY6R09D%40mail-itl.
Re: [qubes-devel] qubes-updates-proxy in dvm
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 On Wed, Nov 17, 2021 at 07:37:28PM +, Zrubi wrote: > On 11/17/21 19:27, Marek Marczykowski-Górecki wrote: > > > Try `systemctl status qubes-updates-proxy` there. > > user@sys-firewall ~]$ sudo systemctl status qubes-updates-proxy > ○ qubes-updates-proxy.service - Qubes updates proxy (tinyproxy) > Loaded: loaded (/usr/lib/systemd/system/qubes-updates-proxy.service; > enabled; vendor preset: enabled) > Active: inactive (dead) > Condition: start condition failed at Wed 2021-11-17 18:49:19 GMT; 43min > ago > └─ > ConditionPathExists=|/var/run/qubes-service/qubes-updates-proxy was not met > > Nov 17 18:49:19 sys-firewall systemd[1]: Condition check resulted in Qubes > updates proxy (tinyproxy) being skipped. > > and the reason is: > -rw-r--r-- 1 root root 0 Nov 17 18:49 > /var/run/qubes-service/qubes-udates-proxy > > the folder name has a typo: > qubes-udates-proxy vs. qubes-updates-proxy > > creating the correct directory fix the issue. > Now the question is who (or what process) creating that wrongly? You, when adding it to qvm-service :P - -- Best Regards, Marek Marczykowski-Górecki Invisible Things Lab -BEGIN PGP SIGNATURE- iQEzBAEBCAAdFiEEhrpukzGPukRmQqkK24/THMrX1ywFAmGVXIkACgkQ24/THMrX 1yyUKQf+LVoqTHUA/yZl9+7MM2bIiX9glVu5IZcZecNMRqHGrVoMmieEoQm1qDSQ 3SY36G9JhyePJCd4yyc5nL9cFTtlFp8jhOxsgJtBGJXeXG0EBDQY4+XSb+mQ38iz M6d3/2UnkGJdZ84gU0bCcNeWSvkur6UXx/vuotkWosD98j31yv4z2gzMcQc7na+R u7xVdVfHma96Q9j+df89zG8DcOrJQEWDonbmqkHiGjpuAraXtF+SZ8fXpNlNYiAI h4VdTp+eZSiHXiJr+fa66xr60viAM3IDPt4jONycZmY6UtAOKOejVIlzFkdu/syl 9qNda1RWSGIUgIaqPjJaqB8F6bU3Wg== =D1E9 -END PGP SIGNATURE- -- You received this message because you are subscribed to the Google Groups "qubes-devel" group. To unsubscribe from this group and stop receiving emails from it, send an email to qubes-devel+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/qubes-devel/YZVciqrrouWmVwe0%40mail-itl.
Re: [qubes-devel] qubes-updates-proxy in dvm
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 On Wed, Nov 17, 2021 at 07:25:23PM +, Zrubi wrote: > On 11/17/21 19:14, Laszlo Zrubecz wrote: > > > unfortunately I don't have any working example any more, so I have to > > create a new vm to see how it is working in a normal VM... > > > > But as I remember for sure, the tinyproxy service should listen on port > > 8082, what I can't see in my case. > > > > I can confirm, in a normal Appvm (whic provides networks for others) working > as expected. > (using the 'factory default' fedora-34 template) > > I see the qubes-updates-proxy.service, and it is listening on the expected > port. > > In case of a factory default sys-firewall, I just can't reach this state - > even the GUI and the CLI show the service enabled, it is not even shows up > by > `systemctl list-units` > > Any advice what to check? Try `systemctl status qubes-updates-proxy` there. - -- Best Regards, Marek Marczykowski-Górecki Invisible Things Lab -BEGIN PGP SIGNATURE- iQEzBAEBCAAdFiEEhrpukzGPukRmQqkK24/THMrX1ywFAmGVV74ACgkQ24/THMrX 1yyGQAf/ezHPLDzuJiAkvCQTGLTvxidUKQuEbHFTsQIPopcx1iY9KPRpHQbmG9jt b1lx/HK3A9e6mvU5zuCEH72xBOs9HhUpCeH59opfG2edNX6rik9LEnx5vAVdeHrJ hJKL4rsDnsq6aoJX6Y/9rk3UoHg+5MDmsNbXoOV8aUL3BKw40ApuyHJ7Ki1TykVY LxOLYH3IPbdb+mfFCEbkYdD9HkveN5+CvL5BR0th80/lgxyyNr11YTjHCcNTI/nb ZeYrE0sdIxgDoU63h/OLbPA/OyRWI6/zv3hQYqhvx0Z+Etleu/RNsdc7ZqMfEEcu agJsLXRl1ZtqxVNUKBIJYD0e0yxaNQ== =8ifb -END PGP SIGNATURE- -- You received this message because you are subscribed to the Google Groups "qubes-devel" group. To unsubscribe from this group and stop receiving emails from it, send an email to qubes-devel+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/qubes-devel/YZVXvoB0oizD%2BRmC%40mail-itl.
Re: [qubes-devel] sys-net hardcoded as a default net-vm
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 On Wed, Nov 17, 2021 at 06:40:01PM +, Zrubi wrote: > On 11/17/21 18:19, Marek Marczykowski-Górecki wrote: > > On Wed, Nov 17, 2021 at 05:05:01PM +, Zrubi wrote: > > > > user@dom0 ~]$ sudo grep sys-net /etc/libvirt/libxl/sys-firewall.xml > > > > > > > > This seems like a hidden property, as not show on the GUI, but not even > > > using qvm-prefs. > > > > It is in qvm-prefs very explicitly: a netvm property of sys-firewall. > > Hmm, then it was just not is sync for some reason: > > name- sys-firewall > netvm - WiFi > > But now the .xml and the output of the qvm-prefs are in sync, so not sure > how it happened - maybe I just missed something. Sorry for the lame question > then :) The libvirt xml is updated at VM startup. So, maybe you haven't started sys-firewall after the change yet? > > > user@dom0 ~]$ grep sys-net /etc/qubes/policy.d/90-default.policy > > > # Default rule for all TemplateVMs - direct the connection to sys-net > > > qubes.UpdatesProxy * @type:TemplateVM@defaultallow > > > target=sys-net > > > > > ^^ Maybe this is triggering it? > > > > This is what templates will use to download updates from, see > > https://www.qubes-os.org/doc/how-to-install-software/#updates-proxy > > So, yes, if you want to use something else, you do need to change it > > (but I recommend creating a new file with lower number and putting your > > rule there - it will take precedence over later rules). > > Yeah, I was found it meanwhile... > And thanks for the advice, makes sense to not mess up the default :) > > > So my 'issue' just shifted to have a qubes-updates-proxy process somewhere > else than sys-net. > > Previously I was running it in my sys-firewall. > Now it is a DVM by default, and I can't find the way how to run the > qubes-update-proxy in this case. It should work the same way, just enable `qubes-updates-proxy` service on the sys-firewall (via qvm-service). While the data inside won't persist (it is a disposable VM after all), its settings will persist. - -- Best Regards, Marek Marczykowski-Górecki Invisible Things Lab -BEGIN PGP SIGNATURE- iQEzBAEBCAAdFiEEhrpukzGPukRmQqkK24/THMrX1ywFAmGVTbMACgkQ24/THMrX 1yx+7wf9EetCr5FIvl7jazUMvGBS3Rss8HIj3xCgO4X8Wl2iEesm8fIFbM3h+nsy 5kdNgqFKRX8juoFFH/a16Pl54Uvke7Zad0fJ3IJ2GQsKImCFIObGByYNNvs1sFo7 /qniVOh8K0bzJUcTaFN1SlvHSc0r2Bd1c9Zjye/KM0wHe2ktdAI75bdqApxW1OPq WNWj6QQ+MhOQ5sA4TeciPza561OLwD5uplZmH/2HiGGfLet+e0nwVCMr0s4Nl1+H 4eIBwl10qidcqJ1jQFfiNA+nh2Aercoa+3TYCyfWLvGNgvifdzqc47MDBUqcDX1h aGkz5fnRxOv3Rg3m9yosS/23P+l5Yw== =Guo3 -END PGP SIGNATURE- -- You received this message because you are subscribed to the Google Groups "qubes-devel" group. To unsubscribe from this group and stop receiving emails from it, send an email to qubes-devel+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/qubes-devel/YZVNs/gjZXqDXIdk%40mail-itl.
Re: [qubes-devel] sys-net hardcoded as a default net-vm
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 On Wed, Nov 17, 2021 at 05:05:01PM +, Zrubi wrote: > Hi, > > I just upgraded to 4.1 which is went fine using the backup and restore > procedure. > > I have found out that the 'sys-net' as a default netvm is hardcoded in some > places. > > Why it is an issue? > becuse I using another netvm (separate WiFi, and Ethernet VMs) by default. > > > I have already changed the default netvm, not any single VM are using the > 'factory defaulf' sys-net any more, but still the template upgrade process > pull this in somehow... > Ending up without net access because of this. > > I have found two reference so far: > > user@dom0 ~]$ sudo grep sys-net /etc/libvirt/libxl/sys-firewall.xml > > > This seems like a hidden property, as not show on the GUI, but not even > using qvm-prefs. It is in qvm-prefs very explicitly: a netvm property of sys-firewall. > user@dom0 ~]$ grep sys-net /etc/qubes/policy.d/90-default.policy > # Default rule for all TemplateVMs - direct the connection to sys-net > qubes.UpdatesProxy * @type:TemplateVM@defaultallow > target=sys-net > > ^^ Maybe this is triggering it? This is what templates will use to download updates from, see https://www.qubes-os.org/doc/how-to-install-software/#updates-proxy So, yes, if you want to use something else, you do need to change it (but I recommend creating a new file with lower number and putting your rule there - it will take precedence over later rules). - -- Best Regards, Marek Marczykowski-Górecki Invisible Things Lab -BEGIN PGP SIGNATURE- iQEzBAEBCAAdFiEEhrpukzGPukRmQqkK24/THMrX1ywFAmGVR6MACgkQ24/THMrX 1yzFWgf9F7u73O1UjzaeQOcB3if85slbkJg/VI4C3te19wx6Ou+IJKp1XgjyN8rZ 23voRMqSjgMcN2+FFuD9jS7QbvnzkKPZcmYoMlhOXDJDDqcETMxWhP+uTH/F28UH uM1VValvTSJToCdckbrltgdMkv2Miux+1+1ZhfRxGYP+ZH5HEgM0LoKag7wltfrO yysB/TsP9NHUwQPzSw4O/KejmfLeZefbNGmv/RZLcs3rkYeYakRGs1o4DgCGGttT JZG43LqWr0X3LrUeFCLmbfVoiSFr2v7NTY7wamGVvEn9o7WpeJkGgRHdyKk6cbGy RSt6WoI6B+XLjvxi6QDEoUwZ/yjxQA== =ukvE -END PGP SIGNATURE- -- You received this message because you are subscribed to the Google Groups "qubes-devel" group. To unsubscribe from this group and stop receiving emails from it, send an email to qubes-devel+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/qubes-devel/YZVHpHYhaNck5nNs%40mail-itl.
[qubes-devel] Hosting for OpenQA instance (again)
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 Hi, It seems our current hosting for openqa.qubes-os.org is no longer a stable option (thanks to the anonymous supported who provided it for the last two years!). Also, the current number of the tests we run makes our current setup barely sufficient. So, we are looking for a new/additional machine to run openqa on: Does anyone have some place/recommendation where to look? Hardware we need: - CPU with VT-x + EPT, so KVM will work with reasonable performance (this means a physical machine, not virtual one) - 8+ GB RAM (6GB for KVM + something for OpenQA itself), preferably 32 GB or more - 500 GB of disk space (preferably more) - fast internet connection, preferably in European location - peak traffic about 200 Mbps, in short bursts (transferring disk images for tests) Does anyone have a spare machine running somewhere, and willing to share? - -- Best Regards, Marek Marczykowski-Górecki Invisible Things Lab -BEGIN PGP SIGNATURE- iQEzBAEBCAAdFiEEhrpukzGPukRmQqkK24/THMrX1ywFAmFuxJwACgkQ24/THMrX 1yyCawgAgDWRPueH/smmNRngYN3mPIHYxhQmvPhUElRl/JR4pYAk9l4btibOZ/4R LwCXppeaTZaa9rIl6wG6peFiEfVd+UkUQQAtOHPnRLR6hdwBoUGueC0d6q2zOqw+ AbZTCSowASkQJLoGiiqdFggVLzhhZnPbOu4HZOByxZ3PzcRUgflzk6lr+SzARI+o bDYze1oTXIuJVIx4sWnnBuNe9iVt8owuG4KliU9E/H4HhIO1uNqCoIcbvluqEMBn z5SoOVSg96ZVIHuCFc2eUQETv6CaBThEPyRvcUu38c/cvx5R0LDrlyxksXa1x564 bBft8ZncDWNHrkQbMwS2BGkF6uzKSQ== =y3br -END PGP SIGNATURE- -- You received this message because you are subscribed to the Google Groups "qubes-devel" group. To unsubscribe from this group and stop receiving emails from it, send an email to qubes-devel+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/qubes-devel/YW7Em2W0xGS03xzU%40mail-itl.
[qubes-devel] Re: Switching to bi-directional stdin when qrexec-agent and child run as different users
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 On Mon, Oct 11, 2021 at 10:35:11AM -0400, Demi Marie Obenour wrote: > On Mon, Oct 11, 2021 at 04:28:01PM +0200, Marek Marczykowski-Górecki wrote: > > On Mon, Oct 11, 2021 at 09:13:18AM -0400, Demi Marie Obenour wrote: > > > On Fri, Oct 08, 2021 at 02:21:58AM +0200, Marek Marczykowski-Górecki > > > wrote: > > > > On Fri, Oct 08, 2021 at 02:12:08AM +0200, Simon Gaiser wrote: > > > > > Hi Marek and list, > > > > > > > > > > a qrexec service started by qrexec-agent (directly or via > > > > > qrexec-fork-server) can request that instead of using stdin and stdout > > > > > both side switch to using stdin bi-directional. To do so it needs to > > > > > send SIGUSR1 to QREXEC_AGENT_PID. > > > > > > > > > > According to the git history [1] this has been added for usbip. As > > > > > hinted in the commit message and in the comment [2] in the code this > > > > > mechanism has a problem. To send a signal you need to be root or run > > > > > as > > > > > the same user as the receiving process. > > > > > > > > > > This lead to a corner case in the Python port of split-gpg2 [3] that > > > > > tried to always switch to the bi-directional mode. During normal > > > > > operation things worked since it's spawned through qrexec-fork-server > > > > > that is running as user. But if the VM wasn't running the qrexec > > > > > service > > > > > in the freshly booted VM is spawned directly by qrexec-agent that runs > > > > > as root and therefore sending SIGUSR1 failed. > > > > > > > > I think fixing that "TODO" shouldn't be that hard. The data handling > > > > process (the one pointed with QREXEC_AGENT_PID) is already a separate > > > > process, and I don't think it needs to keep root privileges. > > > > This should be rather simple change, am I missing anything? > > > > > > I don’t think this is a good idea for two reasons. First, using SIGUSR1 > > > is inherently not very reliable, as it is asynchronous and doesn’t > > > provide any confirmation of signal receipt. > > > > I don't think it was ever an issue, but theoretically you are correct. > > Has this ever had any users other than USB pass-through? If not, it > might explain some of the random failures there. Can you point at some specific bug reports? I'm only aware of two types of USB passthrough issues: - resetting USB device disconnects it (especially an issue for connecting Android phones, which looks like a device reset on mode switch) - unsupported data transfer mode (should be better now, since the current USBIP driver has XHCI support) > > > A better approach would be > > > to pass an AF_UNIX stream socket as file descriptor 3, > > > > Then, the qrexec doesn't know where to send the data... > > I meant to use file descriptor 3 for out-of-band control messages. On > further thought, I would actually prefer a *datagram* socket, I see, but TBH I don't like it that much. This makes writing a service significantly harder, because (in some cases) it is no longer enough to use standard read/write (or kill) which you can do trivially in any language/tool etc, sending/receiving datagram over AF_UNIX is rather uncommon thing (and often even sending UDP packets requires much less common API). On the other hand, I think one can rather easily get confirmation when the parent qrexec processes the SIGUSR1 - simply by waiting for EOF on FD 1. An alternative, is to use socket service. If you don't like an extra process laying around, you can use socket systemd unit, with Accept=true if necessary. But then, you need to read the service call handshake before using it for the actual data (not a big deal). > with > checks that the message actually came from the correct child process. No, that's a bad idea. This forces specific process structure of a service, which will be limiting factor. > > > or else just > > > unconditionally accept data on either file descriptor 0 or 1. > > > > Almost, closing FD 1 must not be sent as EOF (after which, sending more > > data over FD 0 wouldn't be possible anymore). And BTW, a heuristic of > > "don't send EOF on FD 1 close, if any data was received over FD 0 > > already" won't work, as for the usbip connection, the actual data is > > exchanged only after FD is passed on to the kernel (after closing other > > FDs). > > That is true. > > > > Second, > > > thi
[qubes-devel] Re: Switching to bi-directional stdin when qrexec-agent and child run as different users
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 On Mon, Oct 11, 2021 at 09:13:18AM -0400, Demi Marie Obenour wrote: > On Fri, Oct 08, 2021 at 02:21:58AM +0200, Marek Marczykowski-Górecki wrote: > > On Fri, Oct 08, 2021 at 02:12:08AM +0200, Simon Gaiser wrote: > > > Hi Marek and list, > > > > > > a qrexec service started by qrexec-agent (directly or via > > > qrexec-fork-server) can request that instead of using stdin and stdout > > > both side switch to using stdin bi-directional. To do so it needs to > > > send SIGUSR1 to QREXEC_AGENT_PID. > > > > > > According to the git history [1] this has been added for usbip. As > > > hinted in the commit message and in the comment [2] in the code this > > > mechanism has a problem. To send a signal you need to be root or run as > > > the same user as the receiving process. > > > > > > This lead to a corner case in the Python port of split-gpg2 [3] that > > > tried to always switch to the bi-directional mode. During normal > > > operation things worked since it's spawned through qrexec-fork-server > > > that is running as user. But if the VM wasn't running the qrexec service > > > in the freshly booted VM is spawned directly by qrexec-agent that runs > > > as root and therefore sending SIGUSR1 failed. > > > > I think fixing that "TODO" shouldn't be that hard. The data handling > > process (the one pointed with QREXEC_AGENT_PID) is already a separate > > process, and I don't think it needs to keep root privileges. > > This should be rather simple change, am I missing anything? > > I don’t think this is a good idea for two reasons. First, using SIGUSR1 > is inherently not very reliable, as it is asynchronous and doesn’t > provide any confirmation of signal receipt. I don't think it was ever an issue, but theoretically you are correct. > A better approach would be > to pass an AF_UNIX stream socket as file descriptor 3, Then, the qrexec doesn't know where to send the data... > or else just > unconditionally accept data on either file descriptor 0 or 1. Almost, closing FD 1 must not be sent as EOF (after which, sending more data over FD 0 wouldn't be possible anymore). And BTW, a heuristic of "don't send EOF on FD 1 close, if any data was received over FD 0 already" won't work, as for the usbip connection, the actual data is exchanged only after FD is passed on to the kernel (after closing other FDs). > Second, > this would allow the child process to ptrace() the parent process and > obtain access to Xen file descriptors, which could potentially be used > to escalate privilege within the qube. While this isn’t an explicit > security boundary in Qubes OS, my understanding is that Qubes OS doesn’t > try to deliberately weaken it either. Well, user processes must have the ability to open vchan connections anyway, either for qrexec-client-vm to work, or for qrexec-fork-server. > > > For split-gpg2 I switched, at least for now, to always use stdin/-out > > > (maintaining two code paths would be ugly). > > > > > > Do we have plans to improve this? > > > > > > Beside the uspip case, are there any advantages of having a > > > bi-directional stdin? > > > > Yes, I'd consider making split-gpg2 a socket-based service (with one > > process handling several requests, to avoid process startup delay). For > > this, it needs to transfer data over a single socket FD. > > I fully support this, but with two significant caveats. The first is > that one must ensure the socket is present and listening before qrexec > tries to connect to it. This isn’t trivial for a service not running as > root. We could have a system unit with User= setting. > The second is that right now, one can use user= directives in > qrexec policy to control which qube has access to which keys. While > this is not best practice, on memory-constrained hardware it can be the > difference between being able to use split-gpg and not being able to do > so. That's true. In fact it's yet another case, where overriding the call argument at the policy level could be useful (something I consider adding for a long time already) - then you could have different sockets for different users. - -- Best Regards, Marek Marczykowski-Górecki Invisible Things Lab -BEGIN PGP SIGNATURE- iQEzBAEBCAAdFiEEhrpukzGPukRmQqkK24/THMrX1ywFAmFkSfAACgkQ24/THMrX 1ywmewf8CMW2/gkqaS9HUjCmbtzPorNJaeCH12fWsgj1eiA9AY85s4aesF0a74Nr VZOzven0UANGKaVD3ZH77uTi+0h8Wu57QAOvclKzQqTES5MrOdC0WKKqjjGV6WYP Mf1P0w/828/DPcsKt13Og8OchbuFTLX46ricv3W6awyPkd4e3MyJIIP+J/x3qRUd TSvy6/kci4q3YOqUSUu9FjA2t8+FZuHx+KUxMSgQYFDSie1VoVlr5luORkzwDwge Z4DtoRgWwGk7esOV0x9
[qubes-devel] Re: Switching to bi-directional stdin when qrexec-agent and child run as different users
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 On Fri, Oct 08, 2021 at 03:26:11AM +0200, Simon Gaiser wrote: > Marek Marczykowski-Górecki: > > Yes, I'd consider making split-gpg2 a socket-based service (with one > > process handling several requests, to avoid process startup delay). > > For this, it needs to transfer data over a single socket FD. > > But in that case split-gpg2 would open one unix socket and accept > connections there. So the above mechanism wouldn't be needed at all, or > do I miss something? Indeed, switching wouldn't be needed in that case. Using a single FD for both reading and writing would be. - -- Best Regards, Marek Marczykowski-Górecki Invisible Things Lab -BEGIN PGP SIGNATURE- iQEzBAEBCAAdFiEEhrpukzGPukRmQqkK24/THMrX1ywFAmFfogMACgkQ24/THMrX 1yzNvwf/blB33gjzEASn2O8tQVyNX+pU2qzHntidNjacL2InsfB+P7ls7eCozK4l m/sgeujhJHY+n3BpHdoM/U8v6Man5/a080DpSDIFoxG/2GYAvLNZUS4u3yb2afJ8 Nahnv2MdrigWTNm6buhFS+LK0UjF6nIetGOzk9hOFdJi6AZxV8LG18LuvJUtJlue Q0gmmtFnfsd5YbMuYnHSSYWO0AoXfJcnrnryCgHC21ciAHdUhep2GPiIgwe+Jxd6 pcMoBPH36nvPYsZo721Rx/3yEG2Mb5Nz8ychHWIh5LixuqqmkAwTKqhuHJOHqIQ8 fauFvbEGBpSElgGy5ll2NdY3reqHaA== =/2wR -END PGP SIGNATURE- -- You received this message because you are subscribed to the Google Groups "qubes-devel" group. To unsubscribe from this group and stop receiving emails from it, send an email to qubes-devel+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/qubes-devel/YV%2BiBC%2BGndpvZ1Et%40mail-itl.
[qubes-devel] Re: Switching to bi-directional stdin when qrexec-agent and child run as different users
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 On Fri, Oct 08, 2021 at 02:12:08AM +0200, Simon Gaiser wrote: > Hi Marek and list, > > a qrexec service started by qrexec-agent (directly or via > qrexec-fork-server) can request that instead of using stdin and stdout > both side switch to using stdin bi-directional. To do so it needs to > send SIGUSR1 to QREXEC_AGENT_PID. > > According to the git history [1] this has been added for usbip. As > hinted in the commit message and in the comment [2] in the code this > mechanism has a problem. To send a signal you need to be root or run as > the same user as the receiving process. > > This lead to a corner case in the Python port of split-gpg2 [3] that > tried to always switch to the bi-directional mode. During normal > operation things worked since it's spawned through qrexec-fork-server > that is running as user. But if the VM wasn't running the qrexec service > in the freshly booted VM is spawned directly by qrexec-agent that runs > as root and therefore sending SIGUSR1 failed. I think fixing that "TODO" shouldn't be that hard. The data handling process (the one pointed with QREXEC_AGENT_PID) is already a separate process, and I don't think it needs to keep root privileges. This should be rather simple change, am I missing anything? > For split-gpg2 I switched, at least for now, to always use stdin/-out > (maintaining two code paths would be ugly). > > Do we have plans to improve this? > > Beside the uspip case, are there any advantages of having a > bi-directional stdin? Yes, I'd consider making split-gpg2 a socket-based service (with one process handling several requests, to avoid process startup delay). For this, it needs to transfer data over a single socket FD. > Simon > > [1]: > https://github.com/QubesOS/qubes-core-agent-linux/commit/c1cb78e0e8e2e6090c32e2c1cddc9f8bcbd8399e > [2]: > https://github.com/QubesOS/qubes-core-qrexec/blob/339f79a13403ce240e4e0748717d8fb9674b31b3/agent/qrexec-agent-data.c#L215 > [3]: https://github.com/HW42/qubes-app-linux-split-gpg2 - -- Best Regards, Marek Marczykowski-Górecki Invisible Things Lab -BEGIN PGP SIGNATURE- iQEzBAEBCAAdFiEEhrpukzGPukRmQqkK24/THMrX1ywFAmFfjyYACgkQ24/THMrX 1ywkiQf/VQ4pt40jsf/5YTn9OW9hTrfkh7ykMqo+X2Te0VKEuopu8XeBsvyZK1Hv /Up+clWj5RnCI+33jrV4wK56ddRBPiogenyrbBrel36hP0AXBHtljU4lIFmOu388 HbnOo4OQiaTK1ZuHMxaC2t56mThgCCrlarlvw020uzrTncI0nNvgdLmWZf0bgCJX SEgsWpBNzEOdAXia0uY19l0jXM4EvFEEbaE7EaaXqfXyY7D+qtuF9HSNMid58fyN 3FhvtuwHcTBgD2/Vdd9GeU93quCdXtc/H0E7zL0XO8HP/2V0eMkzGG2oWvc5Klrd q747t9tYoKqfgYQj1SvLU4y0Wa1ddg== =7TGX -END PGP SIGNATURE- -- You received this message because you are subscribed to the Google Groups "qubes-devel" group. To unsubscribe from this group and stop receiving emails from it, send an email to qubes-devel+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/qubes-devel/YV%2BPJlBK%2BkJg%2B/Jv%40mail-itl.
Re: [qubes-devel] Re: Should we migrate the documentation to another platform?
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 On Tue, Sep 28, 2021 at 06:06:41PM +, Tobias Killer wrote: > Hello, > > one feature that is often used in Qubes Doc is the automatic generation of > HTML IDs like, for example, if the source Markdown file contains > > ``` > # Hello world > ``` > > the resulting HTML file contains > > ``` > Hello world > ``` > > which means one can link to that heading via `[Link](#hello-world)`. > > Are there pendants in RTD and Wiki? In what way? RTD does that automatically, for example: https://dev.qubes-os.org/projects/core-admin/en/latest/qubes-events.html#handling-events-with-variable-signature But that's for rST input, I'm not sure if the same will work with MD input (likely yes). - -- Best Regards, Marek Marczykowski-Górecki Invisible Things Lab -BEGIN PGP SIGNATURE- iQEzBAEBCAAdFiEEhrpukzGPukRmQqkK24/THMrX1ywFAmFTXgQACgkQ24/THMrX 1yx0xggAir2EbXJT0wEfTtCYy7aT8nhSYl8tjjF2dr2gXaC51C0GZLX7+XZiUxec 5HNFoo6TTFs+51ykmsVjDuuIAa2ekmVKbyty8Kl9FXzXkWtJG774oY6UCfNM+JCd n8jZ5MjzQv6h3adfQP6QcBayPoFnzjwzKilnwsK7c1aMsNkku/jIm8nJ3zkV6omH h/goLMesX6H20SOjLKKsLkiHIg+p01uG6rLJDnxELBNE33Sy/rSC323hDihmr/6K wnWJR2SElqlqpptTa8vyHi41KpVODKBJ7R0SxTKVY4d7y5TJOKyrBbbD98R/uJWm YNTXpHyVCzfEJQ5PQgVRt6VR/+YROw== =Te7J -END PGP SIGNATURE- -- You received this message because you are subscribed to the Google Groups "qubes-devel" group. To unsubscribe from this group and stop receiving emails from it, send an email to qubes-devel+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/qubes-devel/YVNeBGASP5WGKPJQ%40mail-itl.
[qubes-devel] QSB-071: Fatal options filtering flaw in Split GPG
Dear Qubes Community, We have just published Qubes Security Bulletin (QSB) 071: Fatal options filtering flaw in Split GPG. The text of this QSB is reproduced below. This QSB and its accompanying signatures will always be available in the Qubes Security Pack (qubes-secpack). View QSB-071 in the qubes-secpack: https://github.com/QubesOS/qubes-secpack/blob/master/QSBs/qsb-071-2021.txt Learn about the qubes-secpack, including how to obtain, verify, and read it: https://www.qubes-os.org/security/pack/ View all past QSBs: https://www.qubes-os.org/security/bulletins/ ``` ---===[ Qubes Security Bulletin 071 ]===--- 2021-09-09 Fatal options filtering flaw in Split GPG User action required - Users must install the following specific packages in order to address the issues discussed in this bulletin: For Qubes 4.0, in templates and standalones: - qubes-gpg-split 2.0.53 For Qubes 4.1, in templates and standalones: - qubes-gpg-split 2.0.53 Due to the ease with which this flaw can be exploited, we are immediately migrating these packages to the current (stable) repository, bypassing the usual testing period. These packages are to be installed via the Qubes Update tool or its command-line equivalents. [1] Summary Split GPG [2] is designed to isolate private keys from the application using them in order to protect them from being extracted and to allow the user to retain control over when they are used. This isolation is implemented by forwarding calls to `gpg` into a backend qube that holds the private keys and allowing only specific `gpg` options. This option filtering mechanism rejects options like `--export-secret-keys` and others that might leak private keys to the frontend qube. Unfortunately, several options were declared incorrectly, which allowed this filtering mechanism to be bypassed. Impact --- An attacker controlling a frontend qube (where `qubes-gpg-client` is executed) can extract an arbitrary file (including a secret key) from the backend qube. Discussion --- Several `gpg` options were declared incorrectly in Split GPG, which resulted in Split GPG interpreting them differently than `gpg`. If Split GPG interpreted one option as an argument to another option, Split GPG would allow it, since option filtering is performed at the level of the options themselves, not their arguments. This would allow options misinterpreted as arguments to bypass the filtering mechanism. Specifically: - All `--s2k-*` options were declared as not taking arguments when in fact they do take arguments. - `--export-ssh-key` was declared as taking an argument when it doesn't take one directly; it does change the meanings of positional arguments, however. - `--with-colons` was aliased with `-k`, which differs in its argument requirements. - `--default-recipient`, which takes an argument, was interpreted as `--default-recipient-self`, which does not take an argument. - `--display` was interpreted as `--display-charset`, which resulted in `--display` being allowed when it should have been denied. For our immediate, initial response, we have corrected all of these inconsistencies and added automated testing to verify that GnuPG and Split GPG both understand the options in the same way. More generally, we will prioritize finishing Split GPG 2 [3], which does not rely on option filtering at all. Instead, it uses `gpg-agent`'s protocol to delegate only secret key processing to the backend qube. In addition to obviating the need for fragile option filtering, this dramatically reduces the attack surface, as most of the untrusted data processing is done in the frontend qube and never reaches the backend qube. Credits This issue was discovered by Demi Marie Obenour. References --- [1] https://www.qubes-os.org/doc/updating-qubes-os/ [2] https://www.qubes-os.org/doc/split-gpg/ [3] https://github.com/QubesOS/qubes-issues/issues/474 -- The Qubes Security Team https://www.qubes-os.org/security/ ``` This announcement is also available on the Qubes website: https://www.qubes-os.org/news/2021/09/09/qsb-071/ -- You received this message because you are subscribed to the Google Groups "qubes-devel" group. To unsubscribe from this group and stop receiving emails from it, send an email to qubes-devel+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/qubes-devel/YTqHZEE4pC0MGCr1%40mail-itl. signature.asc Description: PGP signature
Re: [qubes-devel] Re: build system does not build, libvirt ?
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256
On Thu, Sep 02, 2021 at 06:01:56AM -0700, ludwig...@gmail.com wrote:
> Here is my builder.conf
This is a config for building Qubes 4.1, not Qubes 4.0. Take a look at
example-configs directory.
Furthermore, I'd recommend keeping DIST_DOM0 unchanged (fc32 for R4.0).
Even if it will succeed to build (which is not that obvious), you
wouldn't receive updates if you build for a different base distro.
As for the build error:
> > sudo BACKEND_VMM=xen chroot
> > /home/build/src/qubes-builder/chroot-dom0-fc33 su -c 'rpmspec -P --define
> > "debug_package %{nil}" --define "fedora 33" --define "dist .fc33" --define
> > "fedora 33" --define "dist .fc33"
> > /home/user/qubes-src/core-libvirt/libvirt.spec >
> > /home/user/qubes-src/core-libvirt/libvirt.spec.parsed' - user
> > cat: version: No such file or directory
> > error: line 275: Empty tag: Version:
... you found a bug.
Fixed here:
https://github.com/QubesOS/qubes-builder-rpm/commit/00bea13e220497efc288ffa14019dda579257723
Execute `make get-sources` again, and retry.
> > Also is there a vm image of a proven good qubes-buidl system, as the build
> > system
> > is very sensitive to moon phase and moisture :-)
Yeah, that is a bit tricky indeed. But a VM image would hide issues we
should fix anyway...
- --
Best Regards,
Marek Marczykowski-Górecki
Invisible Things Lab
-BEGIN PGP SIGNATURE-
iQEzBAEBCAAdFiEEhrpukzGPukRmQqkK24/THMrX1ywFAmEw4mMACgkQ24/THMrX
1yxcHwgAliHkGnK2HoE/Y65DFVw5z5MpCWVyz7d19QQ4YAwMcsKqG7EHm8fGAg7n
45g+HDJx2DhpyFAHEYI1UIsrziGIxCbi3Y5slcFr8FpwyYiz+pDay42ywVPhQhh1
amY4y6MX6Z0oKxgdf1mbnOMaw0oSovzlrgnz7FY4+hcAxsTRweIMTKm+r7WFgmMt
NGMltxYieIEtrDeAqjbHX9fzgXuoPgGSAizekVzBUV6hX/dX5VToH/yOmNNn3kA/
aD+b73YVFGruYFuY9ZkuKYll5CT/2/zJN+bxDcGWdQkx/yrxxo0DL27maoS56uDi
8EhIjsOdY7MV1tZ56ebmwG54Gn5FFg==
=WWUc
-END PGP SIGNATURE-
--
You received this message because you are subscribed to the Google Groups
"qubes-devel" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to qubes-devel+unsubscr...@googlegroups.com.
To view this discussion on the web visit
https://groups.google.com/d/msgid/qubes-devel/YTDiZE7PL0Q8Xtz3%40mail-itl.
Re: [qubes-devel] can not build cubes with qubes-builder
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 On Tue, Aug 24, 2021 at 11:02:22AM -0700, ludwig...@gmail.com wrote: > Hi all, I try to roll my own variant of an qubes install cd and it does not > work to build with system. > > In order to do so, I first try to get a standard qubes-os build environment > up and running and it does not work! > I chose the 4.0 stable and did it according to the documentation on the web > site. > > The machine runs FC33 on bare metal with newest updates > How to get a build environment, that just works? > > with install there were some problems with lib virt. > make qubes step fails. > > -> Preparing fc33 build environment > -> Initializing RPM database... > error: can't create transaction lock on > /home/build/src/qubes-builder/chroot-dom0-fc33/var/lib/rpm/.rpm.lock > (Permission denied) > make[1]: *** > [/home/build/src/qubes-builder/qubes-src/builder-rpm/Makefile-legacy.rpmbuilder:37: > > /home/build/src/qubes-builder/chroot-dom0-fc33/home/user/.prepared_base] > Error 1 > > Any ideas? Yes, one: https://github.com/QubesOS/qubes-issues/issues/6376 A workaround for now: disable SELinux. - -- Best Regards, Marek Marczykowski-Górecki Invisible Things Lab -BEGIN PGP SIGNATURE- iQEzBAEBCAAdFiEEhrpukzGPukRmQqkK24/THMrX1ywFAmElNbAACgkQ24/THMrX 1ywZVQgAiLuxEQ4BtISQqMQe+hzoWW6bJszmSSsBvqsXjYvWZyw8RwPZZpF3+gEz Gc5Tv/NEl2QR/cBCa8315xYOUP9XkLB8e9vQnvOf1pAKnRvrA/F8LtF3tLey8yMG fgdxSVjRu6Y5qBXMewmipf8iKgveQ3rJYGg8FhtYj6N8N7SqCO7W5KZ/yfTROxJH 5GJLcJ+D9S3PzfJmiC0vRtpRJ/jB8YjAjxpIcsb/HmBBlhjY8yr4zOrR6gkn6hmv D0CaKWIHud94J3DlOIGUNH/ofcaewa/M38zkrERbgMtNmOFd1lGFYjtxG83BhFkK aVUlK5qQdSNSKWuzhu3pnof2q5FYFw== =8oQj -END PGP SIGNATURE- -- You received this message because you are subscribed to the Google Groups "qubes-devel" group. To unsubscribe from this group and stop receiving emails from it, send an email to qubes-devel+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/qubes-devel/YSU1sTyJwuJMfyAN%40mail-itl.
Re: [qubes-devel] How to test VNC GuiVM in 4.1?
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 On Sat, Aug 07, 2021 at 01:15:56PM +0200, 'Francois Deppierraz' via qubes-devel wrote: > Hi, > > I would love to be able test the new VNC GuiVM feature in 4.1. > > This commit > (https://github.com/QubesOS/qubes-mgmt-salt-dom0-virtual-machines/commit/6314acbd4fea7367d361fb49dd286d29655c3d6b) > adds support for it but the latest release of the > qubes-mgmt-salt-dom0-virtual-machines package is 4.1.11-1 which doesn't yet > contain this patch. > > Is there somewhere I can find a more recent version of this package or > should I build it myself? That's the way currently. I'm still debugging issues with https://github.com/QubesOS/qubes-mgmt-salt-dom0-virtual-machines/pull/39, will upload new package after that. - -- Best Regards, Marek Marczykowski-Górecki Invisible Things Lab -BEGIN PGP SIGNATURE- iQEzBAEBCAAdFiEEhrpukzGPukRmQqkK24/THMrX1ywFAmESUdgACgkQ24/THMrX 1ywX7Qf+OjyXbwsXx4MOl/AHmGeRsQp7h8KKPMfKmUwbg6NlwMhcajDycb/24Z8d yN2YqXN0I3h+jrPc518xg7SkatLu86islbyxcGNZVUu4Ctp8DSUaSzQ3bzH5q0o0 NGxMi+IYWxanF1Us33tiMGW9xY/7o02Cnh+QheYJqdFv0xTSpp29359iEgTrLuDR r5XhQaEFygYeGi/fmE7/OsEA7s0XG2GKMT31hyPn0n9Dt3IMY4yczZyhiz+aYvt1 JBNOMWJvlaHo0cB4gAWrDQyRiotte2/S1yVHrhoTAJE0z0S30B2J8QgcBy30gehl 3W4SP47OA5S2A7wah5+2vOhI/r3G8g== =+cHx -END PGP SIGNATURE- -- You received this message because you are subscribed to the Google Groups "qubes-devel" group. To unsubscribe from this group and stop receiving emails from it, send an email to qubes-devel+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/qubes-devel/YRJR2XmJeH/MivVf%40mail-itl.
[qubes-devel] Qubes 4.1.0-beta1
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 Hello all, I've uploaded new (officially signed) prerelease of R4.1, it isn't "alpha" anymore, it's "beta". If you feel brave, please test! The installation image can be downloaded from: https://ftp.qubes-os.org/iso/Qubes-R4.1.0-beta1-x86_64.iso https://ftp.qubes-os.org/iso/Qubes-R4.1.0-beta1-x86_64.iso.asc https://ftp.qubes-os.org/iso/Qubes-R4.1.0-beta1-x86_64.iso.DIGESTS https://ftp.qubes-os.org/iso/Qubes-R4.1.0-beta1-x86_64.torrent In-place upgrade - In-place upgrade is also possible: $ sudo qubes-dom0-update --enablerepo=qubes-dom0-current-testing qubes-dist-upgrade Then, look at `sudo qubes-dist-upgrade --help` and follow instructions. You can also watch video of a test upgrade here: https://openqa.qubes-os.org/tests/19727#downloads It starts with installing R4.0 and then proceeds with the update to R4.1. Some extra steps there are to ease diagnosis in the test environment, you don't need to use 'script' tool, nor execute any of the 'sed' commands. The final part is about testing basic functionality after upgrade. Be careful before "STAGE 4" - if you have modified /etc/yum.repos.d/qubes-dom0.repo (for example by enabling testing repositories), after "STAGE 3" you will need to apply changes saved into /etc/yum.repos.d/qubes-dom0.repo.rpmnew manually. There are also few more things not handled by the in-place upgrade yet: https://github.com/QubesOS/qubes-issues/issues/5685 If any stage fails, it should be safe to simply retry (potentially after fixing what it was complaining about). But, in any case, making a full backup before is strongly recommended. Release notes and what remains until final release - -- There are several documentation tasks left, including release notes - draft (some content still in comments) is available here: https://github.com/QubesOS/qubes-doc/pull/828 There are also few remaining code changes to be merged, you can follow it at https://github.com/QubesOS/qubes-issues/projects/6 But even with those tasks not done yet, I've decided to build the "beta" image, so it's easier to test it. At this point, I don't consider any major changes anymore, there will be few minor ones, and a lot of bug fixes. So, it's going to be more and more stable. After merging those few features, there will be R4.1.0-rc1 and the strict release schedule kicks in: https://www.qubes-os.org/doc/version-scheme/#release-schedule Reporting bugs - -- There are many, for sure. The standard place for reporting bugs is qubes-issues repo on github[1]. But, before opening new issue, please search if there isn't one for that problem already. In some cases, it may be better to discuss a problem on a forum first - they issue may be somewhere else than it seems on the first look. We have dedicated category for testing R4.1 [2]. It is also possible to creating a thread on the forum via email - by sending a message to testing-4.1 at forum.qubes-os.org. [1] https://github.com/QubesOS/qubes-issues/issues [2] https://forum.qubes-os.org/c/user-support/testing-4-1/24 - -- Best Regards, Marek Marczykowski-Górecki Invisible Things Lab -BEGIN PGP SIGNATURE- iQEzBAEBCAAdFiEEhrpukzGPukRmQqkK24/THMrX1ywFAmDqW1UACgkQ24/THMrX 1yygdgf/caOfuRJ2g/HptqjO5CoXCgqjI4+aRD7krqmaCEMbGEWy41stzxOB8GF5 u/o/m8HNfDZfcpP0DCJM7jpIs73ds5xByUm94U/e27nckk13YeKrUNvvKE3saLoD a6LOXA5SPFQi/7KtYCWrZM2fbhS8Y7eo5drLs9/jqxI8fYMhz5BMPK3v0wYbXHTy sffqCDdOmC0upHNfZ6Bhju4G9+4jDIm2Gr6j52kVXXEzw5V8Hvc/nmhAGi/8qfB2 Kyrk2AA1jGciXfzg0hmX7twh9wvQ/ASISIpcQVEyL3MyzEXxjGAu/F+Ow2bKmHeY IAZ+DKdwDLdqBp1F6Wc0PMkqRxSprg== =BUJg -END PGP SIGNATURE- -- You received this message because you are subscribed to the Google Groups "qubes-devel" group. To unsubscribe from this group and stop receiving emails from it, send an email to qubes-devel+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/qubes-devel/YOpbVBgawv8wDVRf%40mail-itl.
Re: [qubes-devel] QWT for Qubes R4 with Win10 almost works
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 On Mon, May 24, 2021 at 09:30:12AM -0700, Neal Krawetz wrote: > I think I'm really close to getting Win10 running with USB support under > Qubes R4, but I need some help. > > According to the official docs, Win10 HVM with QWT should have full USB > support: > > https://github.com/Qubes-Community/Contents/blob/master/docs/os/windows/windows-tools.md > But as anyone who has ever tried to install it knows, the installation has > problems. > > As far as I can tell, the main problems are in the installation code for > QWT on the Windows side. > > Here's what I have working so far: > 1. Install Win10 as an HVM. (Baseline.) > > 2. Install 7-zip, since it will be needed to unpack tar files. > > 3. Go to > https://dotnet.microsoft.com/download/dotnet-framework/net35-sp1/. This is > needed to install QWT. (QWT requires .NET version 3.5, but doesn't wait for > it to install. To make it work correctly, install .NET version 3.5 first!) > > 4. Go to https://xenbits.xenproject.org/pvdrivers/win/ and download the > 9.0.0 tar files for xenbus, xenvkb, and xeniface. > Unpack the tar files. > Install xenbus/x64/ and xenvkb/x64/ but do NOT reboot. > No NOT install xeniface -- you'll need that later to fix a missing dll. > After it is installed, reboot. Does installing xeniface here cause any issues? > 5. Go to https://ftp.qubes-os.org/qubes-windows-tools/ and download > qubes-tools-4.0.1.3.exe > Run it. > De-select pvdrivers and migrate user account. > Install. > When it's done, reboot. > > 6. The QWT exe failed to install everything it needs. As far as I can tell, > the CAB file buried inside the EXE didn't install and the installer just > ignored the error. As a result, the Qubes services did not start. (Go to > the Start menu, type Services, and open the Services app. Jump down the > Qubes in the services list and you'll see that they didn't start.) > I suspect that the installer worked under Win7 but does not work under > Win10. > The problem for the missing services comes from two missing dll files: > xencontrol.dll and libxenvchan.dll. Those two are installed as part of "pvdrivers" option, that you deselected in the step 5... But then, I think QWT ships older version of pvdrivers, so selecting that is also not ideal. > xencontrol.dll is in the xeniface.tar file (this is why I had you > downloaded the tar). Copy the dll to "C:\Program Tools\Invisible Things > Lab\Qubes Tools\bin\" and paste it right next to qubesdb-daemon.exe > > libxenvchan.dll is buried inside the exe. This takes a linux system to > extract: > cabextract qubes-tools-4.0.1.3.exe # lots of files, you want "a1". a1 is > an exe that won't run under Win10 > 7z x a1 content.cab # extract the cab file from a1 > cabextract -Flibxen\* content.cab # this extracts libxenvchan.UUID > mv libxenvchan.* libxenvchan.dll > Transfer this dll to some web site and then download it into the Windows VM. > Copy the dll to "C:\Program Tools\Invisible Things Lab\Qubes Tools\bin\" > and paste it right next to qubesdb-daemon.exe > > 7. Reboot the Windows VM. Now the services are running! > Confirm this: Go to the Start menu, type Services, and open the Services > app. Jump down the Qubes in the services list and you'll see that they > started. > > At this point, things that work: > + USB block devices, such as a thumb drive, can be attached to the WinVM. > > Things that do not work: > - USB character devices, like a webcam, yubikey, or smartcard reader, > fail. The error: "qrexec not connected" That is expected, I think. Full support for USB devices is in progress: https://github.com/QubesOS/qubes-issues/issues/5802 > I suspect the problem is that more files in the cab need to be installed > but are missing. Does anyone know what files are needed, where they go, and > what (if any) registry changes are needed? > > Does anyone recognize the problem or have an idea about how to fix it? - -- Best Regards, Marek Marczykowski-Górecki Invisible Things Lab -BEGIN PGP SIGNATURE- iQEzBAEBCAAdFiEEhrpukzGPukRmQqkK24/THMrX1ywFAmCsPVkACgkQ24/THMrX 1yw/Iwf/c3KmhG/ezdR2xxcmHq4k3pDws8DqHjCn4rGTEIZlhaV3LWjluHBVB5rb Qjp2Cm5nzbPGo4aDLdoh2fYPxd51aRyF0c0mZiRSldzO00qcOIJXMlrQriaciCIx POP1CuTHbPJ3ZFWDhFQShKK5Y9RUom432VcRFUqIY5Wfc127c3gss8Nfod2jArqI HiG19yMQq5cv5ytw+0FsWofC4hyARYrjZ/4PJD2zqdlJYvv6Fwembk6Ss/0a+8xU mHQ8dBw6jAsjCCpYR2zl88Ly6ITXuKHGjtWaQ/mFBJZa9ZGdr6LhOM5Cg9E11t6P RDFMkSdlhk6x5Xs1u52AupBJi6lLUQ== =cDGZ -END PGP SIGNATURE- -- You received this message because you are subscribed to the Google Groups "qubes-devel" group. To unsubscribe from this group and stop receiving emails from it, send an email to qubes-devel+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/qubes-devel/YKw9WJTI5jELkr3U%40mail-itl.
Re: [qubes-devel] GitHub ticket #5929 disappeared (official Arch Linux template)
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256
On Mon, May 10, 2021 at 11:56:51AM +, Rusty Bird wrote:
> Marek Marczykowski-Górecki:
> > On Mon, May 10, 2021 at 10:27:38AM +, Rusty Bird wrote:
> > > I was trying to check on the status of the Arch Linux template, but
> > > the issue ticket[1] has disappeared ("Page not found"). Maybe it's
> > > caught in a GitHub spam filter?
> >
> > Likely yes, for some weird reason. I've asked github support to restore
> > it.
>
> After a couple of GitHub API requests, it looks like they're currently
> memory-holing 43 issues:
>
Thanks for the list. Based on it, I've searched the github export I do
from time to time, and I can confirm most of them are not spam (at least
looking at the title, haven't checked the body).
Specifically this list:
https://github.com/QubesOS/qubes-issues/issues/1004
https://github.com/QubesOS/qubes-issues/issues/1017
https://github.com/QubesOS/qubes-issues/issues/1025
https://github.com/QubesOS/qubes-issues/issues/1127
https://github.com/QubesOS/qubes-issues/issues/1510
https://github.com/QubesOS/qubes-issues/issues/1678
https://github.com/QubesOS/qubes-issues/issues/1794
https://github.com/QubesOS/qubes-issues/issues/2196
https://github.com/QubesOS/qubes-issues/issues/2221
https://github.com/QubesOS/qubes-issues/issues/2669
https://github.com/QubesOS/qubes-issues/issues/2804
https://github.com/QubesOS/qubes-issues/issues/2862
https://github.com/QubesOS/qubes-issues/issues/3119
https://github.com/QubesOS/qubes-issues/issues/3272
https://github.com/QubesOS/qubes-issues/issues/3358
https://github.com/QubesOS/qubes-issues/issues/3395
https://github.com/QubesOS/qubes-issues/issues/3402
https://github.com/QubesOS/qubes-issues/issues/3414
https://github.com/QubesOS/qubes-issues/issues/4037
https://github.com/QubesOS/qubes-issues/issues/4056
https://github.com/QubesOS/qubes-issues/issues/4107
https://github.com/QubesOS/qubes-issues/issues/4108
https://github.com/QubesOS/qubes-issues/issues/4240
https://github.com/QubesOS/qubes-issues/issues/4605
https://github.com/QubesOS/qubes-issues/issues/4690
https://github.com/QubesOS/qubes-issues/issues/5033
https://github.com/QubesOS/qubes-issues/issues/5083
https://github.com/QubesOS/qubes-issues/issues/5154
https://github.com/QubesOS/qubes-issues/issues/5204
https://github.com/QubesOS/qubes-issues/issues/5205
https://github.com/QubesOS/qubes-issues/issues/5325
https://github.com/QubesOS/qubes-issues/issues/5334
https://github.com/QubesOS/qubes-issues/issues/5582
https://github.com/QubesOS/qubes-issues/issues/5928
https://github.com/QubesOS/qubes-issues/issues/5929
https://github.com/QubesOS/qubes-issues/issues/6415
https://github.com/QubesOS/qubes-issues/issues/6422 (dupplicate of 6415)
https://github.com/QubesOS/qubes-issues/issues/6451
https://github.com/QubesOS/qubes-issues/issues/6452 (dupplicate of 6451)
That said, many of them are misplaced and were immediately closed as
"invalid" as they should be rather posted to forum or ML.
I'll add them to the list in github support request...
- --
Best Regards,
Marek Marczykowski-Górecki
Invisible Things Lab
-BEGIN PGP SIGNATURE-
iQEzBAEBCAAdFiEEhrpukzGPukRmQqkK24/THMrX1ywFAmCZODAACgkQ24/THMrX
1ywp2Qf+Km1AKKPvsC4lUx9Lra0MfpJAiSMVm8dccQWyWrokO+VjDqF+mB5wrBvX
6j4hBxngg1BfWlPwLblC1oX8S+GtEjc9CHrGI3vpYYB1acl4p48KTK5wTQorv3um
niYJCcQWEQNj0EYRSW0pGgnSMq7hm4/a6N44sLyyveOV9RwX96J9UnM+sCBF1WyT
OjL7RAqbVtrl7qdXJKxByG2M0TVCw391QhOQosFsjdJMdWL6soG+0Fm361sa4JfV
LaA3SMhEEpHcxyzzQo3y5U4royGLBiUDRh683hzW6X9IyFTb9w2c1rwoypG4CqJT
4tYHj8jxFg2CRR86KY8biTw2Mlagzg==
=VMuG
-END PGP SIGNATURE-
--
You received this message because you are subscribed to the Google Groups
"qubes-devel" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to qubes-devel+unsubscr...@googlegroups.com.
To view this discussion on the web visit
https://groups.google.com/d/msgid/qubes-devel/YJk4MOSZRDKoIDnS%40mail-itl.
Re: [qubes-devel] GitHub ticket #5929 disappeared (official Arch Linux template)
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256
On Mon, May 10, 2021 at 10:27:38AM +, Rusty Bird wrote:
> I was trying to check on the status of the Arch Linux template, but
> the issue ticket[1] has disappeared ("Page not found"). Maybe it's
> caught in a GitHub spam filter?
Likely yes, for some weird reason. I've asked github support to restore
it.
- --
Best Regards,
Marek Marczykowski-Górecki
Invisible Things Lab
-BEGIN PGP SIGNATURE-
iQEzBAEBCAAdFiEEhrpukzGPukRmQqkK24/THMrX1ywFAmCZEcoACgkQ24/THMrX
1yx6Mgf/cSsfJuvZFeJQWxUSrSQUBRMa0YZLlojZOIMx16JRpz00ndbAD6IWdKUx
oky6YzesxFiiCgTpI9X5WFZVIuPgSqH6fND8CIc7hTuerabh/NMdGBSNGGBxrw7q
zKQkamLRFR0elLkcCJVAdZStlBUXVZzjZmlk+fRCxFryH6weDtSstdXYtzThGnUo
boTZ1aLF5soMd8vcdTgZCE1qv3kwDGPO9kOtzuhW0ZNpj12gF16KMywyj1vA8DMq
UJ9EQwv8bNPNPLsl/BITd0BgWuhqWrZM8EfesHpNUeZZa0+5r2jfRIhMQ8eT+QPs
XvbbpqQO9plJLbUuhX8WpLEqQz+U8Q==
=wKBV
-END PGP SIGNATURE-
--
You received this message because you are subscribed to the Google Groups
"qubes-devel" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to qubes-devel+unsubscr...@googlegroups.com.
To view this discussion on the web visit
https://groups.google.com/d/msgid/qubes-devel/YJkRys3oNzd8DKUP%40mail-itl.
Re: [qubes-devel] Introducing: Qubes Video Companion v1.0
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 On Wed, Apr 21, 2021 at 05:41:56AM +, 'Elliot Killick' via qubes-devel wrote: > Hello, everyone! Hi! > Starting this past early September, I've been working on and off to > create a new tool for secure webcam integration in Qubes OS out of > /absolute necessity/ for remote work at both my (new) job and school at > the university I'm newly attending. The tool is called Qubes Video > Companion and I'm proud to announce that it's evolved far past that > basic requirement and at version 1.0.4 is now publicly available for > testing! This looks awesome! (...) > 2. Do video conferencing in any qube with qrexec+usbip (with a sys-usb > qube; can't be done from dom0) > > Even disregarding my personal hardware issues above, qrexec+usbip is a > mess to get working and does poor on performance according to this > GitHub issue: https://github.com/QubesOS/qubes-issues/issues/4035. > Although, I've never been able to test it out myself. Additionally, the > security concerns of using TCP/IP and USBIP between qubes is there. A small clarification: qvm-usb does not use TCP/IP. It is running USBIP protocol over qrexec instead of TCP (apparently kernel driver doesn't care ¯\_(ツ)_/¯ ). Otherwise it is all correct. (...) > Repo can be found here: > > https://github.com/elliotkillick/qubes-video-companion > > I spent a lot of time trying to make this a "just works" (and well) > experience (discounting just a couple of hiccups in the FAQ of the > README and GitHub Issues) as I would've wanted back in September (or > earlier) so please star the repo if my project achieves that for you. > Otherwise, create an issue and I'll try to diagnose and fix the problem > you're having as soon as I have a moment. I've read the README there and it all looks really well thought and made! As you noted in the issue #2, integrating it into devices widget would be awesome too. In fact, qvm-usb has quite similar architecture to Qubes Video Companion - there is qubes.USB qrexec service that is called from usb-device-wanting qube, to sys-usb. To facilitate it from dom0 level, there are two extra services: qubes.USBAttach and qubes.USBDetach. You can find it here: https://github.com/QubesOS/qubes-app-linux-usb-proxy/tree/master/qubes-rpc Plus a dom0 part to plug it as a "device": https://github.com/QubesOS/qubes-app-linux-usb-proxy/blob/master/qubesusbproxy/core3ext.py It's a bit clumsy design (make a dom0->qube1 connection, to trigger qube1->sys-usb connection), but it works, reliably. This will work for a camera. For screen share, not really - you have too many options (N x N matrix, instead of 1 x N). But maybe that isn't a problem (to have GUI for camera only)? > As for contribution to the Qubes Community Repo (if that is to be > desired) I first want to fix the issue with Firefox (see the GitHub > issue) because Mozilla has been a great supporter of Qubes with the big > grant they gave so it's the least we could do as well as to not put > Firefox at a disadvantage. Yes, having this in community repo would be fantastic! In fact, I'd even consider adding it into the main repo and have it installed by default! But for that, we need more testers, proper review etc first. - -- Best Regards, Marek Marczykowski-Górecki Invisible Things Lab -BEGIN PGP SIGNATURE- iQEzBAEBCAAdFiEEhrpukzGPukRmQqkK24/THMrX1ywFAmCAZHMACgkQ24/THMrX 1yxM/wf/ZS/2NOegExrqhio9kI+HuZYL2dE2dPNWwRivObWeCZJawrX2P93u2Lws /h2xhgZTr7ge8nQYGCzsMXxvOnDfEEmdolC6PL1JTphAaI5o2mdb0ZNu+B4Pjnb9 KJtWaZ0PXBzG6xvVproaIqRnz4Zaq+IKWw77WXxCYMHdoa0/U/eOB2S1JFEOgPMI 5Qu5Xu94XwfxRqlIlz28/YTvhIiAgybH7fK0T4kJ834Zt3VOZTtABtRpYHtiJnnQ vzL4wCpF/bvnr3nbOoMnS3ahDDSXdG5fYHAneqCit5VSD7PLGnSUiKLI8kRoAaj6 LGH43kRRGHLcxBgCYfknMsoXrhlL+w== =fBCr -END PGP SIGNATURE- -- You received this message because you are subscribed to the Google Groups "qubes-devel" group. To unsubscribe from this group and stop receiving emails from it, send an email to qubes-devel+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/qubes-devel/YIBkc3KsSGMwGE99%40mail-itl.
Re: [qubes-devel] [qvm-backup-restore] Why --rename-conflicting modifies restored VM name and not the old one?
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 On Thu, Apr 08, 2021 at 04:07:07PM +, 'blxxd' via qubes-devel wrote: > My use case is migration between devices, I create backup on primary laptop > and restore it on secondary. To achieve this I remove existing VMs first and > then restore backup because Yes, this is how we envision using backup for this purpose. For disaster recovery, we also have an option in the installer to avoid creating any VMs - this way you get empty system you can restore your VMs into. But note the backup restore has also another important use case - restoring some VMs because you just want to retrieve some data from them (for example you deleted too much, or need to access some older version of a file). In this case is it very undesirable to replace your current VM with the old copy - rather restore under a different name and likely remove that restored VM after you retrieve data from it. > if I restore backup first I will have to rename almost 20 qubes manually > which is virtually impossible to do on a weekly basis. > It makes me feel uncomfortable to remove VMs before restoring backup so I'm > looking for ways to avoid this. Now I see two solutions: > 1. Write a tool that will preserve old ones under different names and rename > restored VMs to original names > 2. Modify backup restoring process so existing VMs would be renamed and not > restored ones > > I like the second one but don't know if there is any downsides. Can you share > your thoughts on this? Thanks Renaming VM may have huge implications. Here are example issues: - for example if that is a template - what should happen to already existing VMs based on this template? should they be referring to now renamed template? or the just restored one? - similar question to network relation - if you restore sys-firewall, should existing VMs refer to the old one or the new one? - you cannot rename running VM (which may include the VM you use to access the backup archive itself) - in this case, you cannot restore the backup of such VM other way than restoring to a different name... - if you rename existing VMs during restore, if restore fails for any reason you could end up with a mixed set of old and new VMs - something even harder to recover from So, I think for your purpose the first approach would work better. Because you can shutdown all the VMs at this point, but also have clear expectations about the final state. If you don't need to restore any VM that is running during the restore process itself, you could even rename them before restoring to avoid the conflict. Some option to make this use case easier, is to have a mass-rename tool, that you can apply before restoring the backup. Currently full rename is implemented in GUI tool only, which makes it hard to automate. If you worry only about data and not VM settings, then there is also another possible option to implement: our storage subsystem (all but the old "file" pool) support volume revisions you can rollback to. By default they are limited to one revision back (and a revision is created each time you shutdown a VM), but it is configurable (revisions_to_keep parameter, see qvm-pool and qvm-volume tools). Now, restoring a conflicting VM could restore the data as a new revision of a storage volume. Then, if you don't like that, you can easily revert to the old one. While technically possible to implement such approach, it also has its own drawbacks: - this applies only to data, not metadata (VM settings etc) - reverting to older revision is not reversible (you cannot switch back and forth) - you cannot start both old and new versions at the same time (to copy data between them for example) - -- Best Regards, Marek Marczykowski-Górecki Invisible Things Lab -BEGIN PGP SIGNATURE- iQEzBAEBCAAdFiEEhrpukzGPukRmQqkK24/THMrX1ywFAmBvQUEACgkQ24/THMrX 1yy1MwgAlK5OPkgW0eX+121eGEhL4M51fcY/M8NlcyMNA7vCQ46slDr5MSVCRG70 WAKrmnz3EYbODPPJbom0i6Iu+r+dm17eaZ5/l0gyX3WbymPXe/GGl6vOVImPFIOK lyYkcZ2c2peDv2KTuAPcU2EhcgVUHQxxEe66t3TEorWLg99MtPj7yH6XeBOmkZgM vYAlThFtEImhZfEi16Df6NkZK31WxfQFDcgEkQd1jser0n9/tINK1xw3S+SB9TML cmjP1xJVbZcHfJ5eAGI6XLE2UAW3t5enDLcSrBSL796a1heSXKNMIZgSLXCaUKh1 Oa+K9H6MW8DWyF074GKv5UG0WzTkbg== =rV6p -END PGP SIGNATURE- -- You received this message because you are subscribed to the Google Groups "qubes-devel" group. To unsubscribe from this group and stop receiving emails from it, send an email to qubes-devel+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/qubes-devel/YG9BQK3bsS/iAYHT%40mail-itl.
[qubes-devel] Re: Vagrant for generating VMs
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256
On Fri, Apr 02, 2021 at 10:52:13AM +0200, Frédéric Pierret wrote:
> Hi,
>
> We had a discussion with Marek yesterday about how we can renew the way we
> build our templates. For example it would be very much convenient to have
> sample piece of file like a Dockerfile as an input to generate a VM. This is
> something I've already experimented and done in other projects. Even if it's
> very convenient for a building process, it is not in the standard for VMs. My
> opinion is that we can go further by using for example a more flexible and
> adopted format with several configuration backends like Vagrant with the use
> of Vagrantfile.
A bit context why "like a Dockerfile" but not Dockerfile specifically:
docker is about containers, not VMs. While most of it would be the same,
containers operate on a bit higher level and lack few parts that we need
in a VM, specifically:
- disk partitioning and creating filesystem
- bootloader, kernel, modules etc
It isn't a deal-breaker, those parts could be added outside of
Dockerfile. But if there is something that would handle it all, it would
be better.
> We see two subjects related to Vagrant:
>
> 1) Use a Vagrantfile as an input for what will be inside our templates. We
> need to adapt our linux-template-builder + pieces in
> builder-{rpm,debian,archlinux,gentoo}. Here, it's currently out of
> consideration to use pre-built images from somewhere like we would do with
> Vagrant or even Docker by pulling external images. We recreate from scratch
> the "box" then ship it as usual in a RPM as our current templates.
>
> Of course, we would still support the legacy way somehow but this would be
> the occasion to make our template builder maybe less qubes-builder dependent.
> Also, it would allow to have a more standalone tool for which any user could
> benefit in creating their own templates in place of post applying Salt
> formulas directly on Qubes templates which are not all the time user friendly.
> 2) Share your AppVM!
>
> We are thinking to add a way to create AppVM easily by using Vagranfile with
> a Qubes integration. A naive approach would be to use StandaloneVM cloned
> from Qubes templates then doing what's inside the Vagrantfile but this is
> something we don't want to do at first. We want to use advantage of AppVM and
> starting for example by:
>
> - identify instruction about which Qubes template to use,
> - identify persistent/non-persistent instructions.
>
> Every instructions like installing packages would be triggered into the
> underlying requested Qubes template then, the others in the AppVM (mostly
> configuration or local user installation). Thinking again of Salt formulas,
> we integrate a way of customization which is from my opinion very convenient
> (not speaking of Ruby syntax ;) ). But, as Vagrant supports Ansible, Salt,
> etc. as customization configuration, we don't lost our current Salt formulas
> at all! For those who want to keep them, just put the trigger to needed ones
> in the Vagrantfile.
>
> 3) Create complex Qubes infrastructure:
>
> We have several topics where we setup service infrastructure into Qubes (e.g.
> https://github.com/QubesOS/qubes-infrastructure or
> https://github.com/fepitre/qubes-mgmt-salt-qubes-server/tree/devel-140320).
> With a focus on services, currently I'm testing and use in production
> docker-compose to create services (e.g.
> https://github.com/fepitre/package-rebuilder). Switching this simple piece of
> file to more Salt formulas to use service in AppVM is not really something I
> want to do because it's not as user friendly as docker-compose when updating
> the services code, restarting, etc. That would be another example where using
> only a Vagrantfile to handle multiple VMs at once could be a benefit to use
> Qubes as a "secure services platform".
>
>
> Having a proper Qubes integration, we could think having/using a community
> hub where we could push/share Vagrantfiles for creating AppVMs/StandaloneVMs
> from Qubes templates. Once again, only the descriptive instructions would be
> used and all would be done locally like you would do it currently with Salt
> formulas.
>
> Any feedback is welcomed :)
The above is some high level idea how to make building new templates
and custom setups easier. Before talking details, we need to answer some
basic questions:
1. Whether such thing would be useful at all? Or maybe our current
pre-built templates (and template-builder scripts) + Salt is enough?
2. Is Vagrant the right too for the job?
If we'd go in a direction like this, I'd strongly prefer to re-use some
existing well known tool. Integrating anything into our custom
qubes
Re: [qubes-devel] [GSoC 2021] Project idea: Simplified external port forwarding and automatic NAT traversal
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 On Sat, Mar 20, 2021 at 10:44:10AM +0100, Giulio wrote: > Hi, > does anyone have time to mentor or further discuss this proposal? Generally, I think easy port forwarding and/or NAT traversal (and maybe also inter-qube connections too?) would be a good GSoC project. And indeed the current "easy" solution is TCP only, which has its limits. I do have concerns expressed in my previous email about this being a potential footgun, but I think this can be solved with appropriate UI (clearly showing if/when a qube has some ports forwarded) and also by having strict opt-in options for that. If you wish to pursue this project, I'll be happy to mentor it, perhaps with someone as a co-mentor (Frédéric?). PS please don't top-post. > On 3/1/21 3:16 PM, Giulio wrote: > > Hello, > > thanks everyone for the comments and inputs. > > > > > >> On 2/17/21 7:27 PM, Marek Marczykowski-Górecki wrote: > >>> > >>> Since some time there is an easier way: > >>> https://www.qubes-os.org/doc/firewall/#opening-a-single-tcp-port-to-other-network-isolated-qube > >>> > >>> It isn't fully automatic, but _much_ easier than manual iptables rules. > >>> > > > > This is surely an improvement over the manual iptables rules. However > > it's TCP only, and thus, for example for torrent or other media > > applications it is not sufficient. Furthermore, if I get it correcly, if > > the number or qubes and forwarded ports involved grows, it would be hard > > to keep track of the network flows. > > > >> On 2/20/21 9:28 PM, Demi M. Obenour wrote: > >> I have mixed feelings about this. > >> > >> On the one hand, this is indeed risky. On the other hand, P2P > >> applications are currently crippled except in sys-net. Some protocols > >> can fall back to TURN servers, but that doesn’t always work and is > >> at best a fallback behavior. I have personally hit this problem more > >> than once. NAT traversal and port forwarding aren’t something > >> everyone needs, but for those who *do* need it, it is extremely > >> difficult to work around the lack of it. > > > > It is indeed an 'hard' issue for those using Qubes at the workplace. In > > the context of a penetration tester, this is especially limiting, > > because as it is now, it introduces a lot of additional work that can be > > a huge issue in time constrained engagements. Being able to forward > > ports faster than it is now would help both for fast file sharing with > > colleagues, payload hosting, reverse shell listeners and much more. > > Furthermore, since port forwarding is used a lot, an overall view to see > > the port forwarding status would help keep tracks of potential holes > > introduced. > > > >> > >> IMO, port forwarding and NAT traversal should be clearly separated, > >> as the use-cases are extremely different. Port forwarding is used > >> to expose a server to the outside world, whereas NAT traversal is > >> used for P2P communication. Furthermore, my understanding is that > >> port forwarding usually needs to be persistent, whereas NAT traversal > >> usually does not. And port forwarding often requires a specific port > >> to be forwarded, whereas for NAT traversal I would not be surprised > >> if the system can choose the port > > I totally agree that separation would be a good idea. > > > >> > >> I agree that allowing a qube to set up its own port forwarding is a > >> Bad Idea in most cases. That said, it should be possible to set up > >> port forwarding via the Admin API, with fine-grained access controls. > >> So it should be possible to express, “Qube X can request port Y > >> to be forwarded to it,” as a qrexec policy. In practice, however, > >> I expect most users to manage port forwarding from the management qube. > >> > >> NAT traversal is a different matter altogether. It is already > >> possible for a qube and a peer that are *trying* to establish a P2P > >> connection to do so, by means of a brute force attack. Nobody does > >> this in practice, because it requires (on average) somewhere around > >> 65536 outgoing connections from each side, which is a good way to > >> overload firewalls. But it can be done, assuming that all outgoing > >> UDP traffic is allowed. And there are a large number of applications > >> that need it. These applications often need to set up and tear down > >> connections at will. > >> > >> Overall,
Re: [qubes-devel] Cleanup on qubes file server (bruschetta)
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 On Sat, Mar 20, 2021 at 04:20:20PM -0700, Andrew David Wong wrote: > On 3/20/21 12:09 PM, Frédéric Pierret wrote: > > > > > > Le 3/20/21 à 1:42 PM, Marek Marczykowski-Górecki a écrit : > > > On Sat, Mar 20, 2021 at 09:38:19AM +0100, Frédéric Pierret wrote: > > > > > > > > > > Le 3/20/21 à 3:20 AM, Marek Marczykowski-Górecki a écrit : > > > > > Hi, > > > > > > > > > > I want to do a little cleanup on the server, to make more room for the > > > > > packages. Here is the disk usage of repo/yum/ dirs: > > > > > > > > > > 472M r1 > > > > > 19G r2 > > > > > 18G r3.0 > > > > > 21G r3.1 > > > > > 59G r3.2 > > > > > 157G r4.0 > > > > > 71G r4.1 > > > > > 342G total > > > > > > > > > > Based on the stats[1] (which are built based on the updates server > > > > > hits), versions below 3.2 are basically unused. So, I'd like to remove > > > > > them from the server. In fact, since 3.2 is EOL for almost 2 years > > > > > already, I think this also could be removed (there won't be any new > > > > > updates there, ever). Does anyone see any reason to keep > > > > > them online, on > > > > > the same server, under same URL? Note this content is also mirrored, > > > > > so > > > > > removing it from here will also reduce storage usage on all > > > > > the mirrors. > > > > > > > > > > [1] https://www.qubes-os.org/statistics/ > > > > > > > > > > > > > > > > > Marek, > > > > If you want, as a history backup, I can keep them somewhere from > > > > my side. > > > > > > Yes, that would be helpful. > > > > > > > > > > > > > It's archived here: https://qubes.notset.fr/archive/repo/yum/ and I've > > backed up it elsewhere too. > > > > You can safely make some space :) > > > > Do we have to update any links on the downloads page? No, ISO images (for now) stay where they were. I'll add a README file where the old repos previously were - to help finding them if anyone needs. - -- Best Regards, Marek Marczykowski-Górecki Invisible Things Lab -BEGIN PGP SIGNATURE- iQEzBAEBCAAdFiEEhrpukzGPukRmQqkK24/THMrX1ywFAmBWiKMACgkQ24/THMrX 1yyS7Af+KFNApykTWRLb2Efy3eOTO486R6C4Mdg3aITxNmp2HXcZYuaMFIzDmlbc CqbRP9+fKB5rEPEyvaOyQ9GEXM4VFsS6PIv4lZOr7agfz9ts7cBi4oGIxkIiUDfo UbgbuQvZB2ERKAwbe5EKa7xofEa/ePklzs6Q89HaOMX/4dXFR9cvpEAi2m+YZxcm z74KiBcqbhGJuLdzDDsCeXZhZP4FVgvTv7UH3bwaknLmLJFqHsebFKB45LIcjviz ert0utnt1lCjeNmPWxbxeq2JWzdZj12TQ7YMsCPiU7B/goeTIuEL/zfJBq6QspST xgcFo3RG/K1X3FnJfWyJ1rNVJYyDzg== =VsSQ -END PGP SIGNATURE- -- You received this message because you are subscribed to the Google Groups "qubes-devel" group. To unsubscribe from this group and stop receiving emails from it, send an email to qubes-devel+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/qubes-devel/YFaIowdm1QwD0ii8%40mail-itl.
Re: [qubes-devel] Cleanup on qubes file server (bruschetta)
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 On Sat, Mar 20, 2021 at 09:38:19AM +0100, Frédéric Pierret wrote: > > > Le 3/20/21 à 3:20 AM, Marek Marczykowski-Górecki a écrit : > > Hi, > > > > I want to do a little cleanup on the server, to make more room for the > > packages. Here is the disk usage of repo/yum/ dirs: > > > > 472Mr1 > > 19G r2 > > 18G r3.0 > > 21G r3.1 > > 59G r3.2 > > 157Gr4.0 > > 71G r4.1 > > 342Gtotal > > > > Based on the stats[1] (which are built based on the updates server > > hits), versions below 3.2 are basically unused. So, I'd like to remove > > them from the server. In fact, since 3.2 is EOL for almost 2 years > > already, I think this also could be removed (there won't be any new > > updates there, ever). Does anyone see any reason to keep them online, on > > the same server, under same URL? Note this content is also mirrored, so > > removing it from here will also reduce storage usage on all the mirrors. > > > > [1] https://www.qubes-os.org/statistics/ > > > > > > Marek, > If you want, as a history backup, I can keep them somewhere from my side. Yes, that would be helpful. - -- Best Regards, Marek Marczykowski-Górecki Invisible Things Lab -BEGIN PGP SIGNATURE- iQEzBAEBCAAdFiEEhrpukzGPukRmQqkK24/THMrX1ywFAmBV7aUACgkQ24/THMrX 1yz1LggAiRUbHPm1zJQv7KNTmUhEbJPV1kiVlrG6Bjyb8nl7znxoqSOwD6WP+sTk WNtaeJOt3xpdZenn9v2clwBhPfY8CkZKCeLYe0PiSBYrRIKHEcLF+KE+ZHj/d9vB sTGpKABBD7BUb3Bt+I5Gb6STYJuiPtoTKIfuSqCFhDWK/JyXFOSYQxXYaZ1wAyau Xx8znvf12ry6zQ43L9mOR7t4JNT9P/KJqCB1v1sZMf2AfiHBN1M0twnWQ9GS1AMG YrGVsQhtUijkPggkWlSADdEF/GGJXfRR/jsFeLR1AtS5x+I5CcyhvViFaqIg0XIm cxQbqN4eUvLqNnK3eBbzwdjS1EySGA== =QI0n -END PGP SIGNATURE- -- You received this message because you are subscribed to the Google Groups "qubes-devel" group. To unsubscribe from this group and stop receiving emails from it, send an email to qubes-devel+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/qubes-devel/YFXtpf5Xs4mVdC8/%40mail-itl.
[qubes-devel] Cleanup on qubes file server (bruschetta)
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 Hi, I want to do a little cleanup on the server, to make more room for the packages. Here is the disk usage of repo/yum/ dirs: 472Mr1 19G r2 18G r3.0 21G r3.1 59G r3.2 157Gr4.0 71G r4.1 342Gtotal Based on the stats[1] (which are built based on the updates server hits), versions below 3.2 are basically unused. So, I'd like to remove them from the server. In fact, since 3.2 is EOL for almost 2 years already, I think this also could be removed (there won't be any new updates there, ever). Does anyone see any reason to keep them online, on the same server, under same URL? Note this content is also mirrored, so removing it from here will also reduce storage usage on all the mirrors. [1] https://www.qubes-os.org/statistics/ - -- Best Regards, Marek Marczykowski-Górecki Invisible Things Lab -BEGIN PGP SIGNATURE- iQEzBAEBCAAdFiEEhrpukzGPukRmQqkK24/THMrX1ywFAmBVW+MACgkQ24/THMrX 1ywpywgAkOF7WqVS7plGAYIWp7DKS56KgOog6yUggM9HlrPnyFRBsCOWA1Ov1Czc oHme7mdGyvFnIAU1xNbauqYGLH6zWNRJYA519nj0gpXneivYm69Af/Do++jKkWG9 CjpWfd02m/6nYZ9lLyuKwEIfBtEkDlDJcg2H86w9ZqnMvS+bLaKq1hUw3xP7jBdc Cfoh1OzWioqOafR/HZrsxtuooplbQiWa1cnvu7QrwH8LJF2JYjAIcQJbCwUYTfSi IzLIWZTmpRJHZARz7SMh2jbJBDhIl/Vlp8wZZv/K4zgWvMNr/+FZaZcvhzs5Vx03 hBQQJJKnLsoV1x6pAwwg1hzjpFURQw== =YXzj -END PGP SIGNATURE- -- You received this message because you are subscribed to the Google Groups "qubes-devel" group. To unsubscribe from this group and stop receiving emails from it, send an email to qubes-devel+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/qubes-devel/YFVb4zcNJbTI0uD3%40mail-itl.
Re: [qubes-devel] broken dom0 updates, shall I report this at qubes-issues?
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 On Fri, Mar 19, 2021 at 03:07:48PM -0500, Sven Semmler wrote: > On 3/19/21 2:03 PM, Marek Marczykowski-Górecki wrote: > > Are you sure you don't have security-testing or current-testing > > enabled? Those packages are currently only there. > > I had it enabled once to see which packages would update, but did not say > yes ... so they might have been cached in the updatevm? It is possible, yes (if you haven't restarted your updatevm since). - --clean option mentioned below will remove that cache too. > > You can retry with `qubes-dom0-update --refresh` > > That tells me "Command line error: no such option: --refresh" Ah, you probably have Debian-based updatevm, which doesn't support this option. Then, use --clean. - -- Best Regards, Marek Marczykowski-Górecki Invisible Things Lab -BEGIN PGP SIGNATURE- iQEzBAEBCAAdFiEEhrpukzGPukRmQqkK24/THMrX1ywFAmBVNUAACgkQ24/THMrX 1yzuIQf+KBgA5ZzqIInCoCcJD7Lebm3d9Nymq4hLFBOprKe8yOj+N98diKBNDHg4 4x+yCAWlP5F4wXxSW1H5BoytweRVyCkJIWThXfj5Ci1aTLAuH2EK1P3BfVbtrgw1 9cR2kGOINlDsYPX7Yt7YXysjoADC25DnWgSn2NzMY19PgPNmb6F10GYATdABrypO 7vbgvGxmQ01UYBSkUp0ZwjQZAtXUI0SkInqHbCRybS/FZ1KWHyjJEVu0SPjbPeyq xyhQ3/dNlQexhTNyUwRx9HBKmc5JALUNA4xO7eO5yuN6PMNYcBo7NTzWBX50TKzE gmGHbhJbJh7dnkqvffbAcdE/BsPucA== =sSQe -END PGP SIGNATURE- -- You received this message because you are subscribed to the Google Groups "qubes-devel" group. To unsubscribe from this group and stop receiving emails from it, send an email to qubes-devel+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/qubes-devel/YFU1QTsvO53ZNEM8%40mail-itl.
