Re: [qubes-users] Inconsistency between `qvm-template list` and `qvm-template-gui`
Without seeing the screenshot, I think I know the issue. They are from the same repository. qvm-template lists *all* the template in the repo, whereas qvm-template-gui filters to only show the most recent supported versions. -- I never presume to speak for the Qubes team. When I comment in the mailing lists I speak for myself. -- You received this message because you are subscribed to the Google Groups "qubes-users" group. To unsubscribe from this group and stop receiving emails from it, send an email to qubes-users+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/qubes-users/Zfq6MxZ7JMd5HZqM%40thirdeyesecurity.org.
Re: [qubes-users] Ethernet socket device not available in Network Connections
[quote] my sys-net is also sys-usb because I used the USB ethernet adapter so I think this is the problem but I don't know how to fix. [/quote] I doubt that this is the problem. Have you assigned the device to sys-net in the "devices" tab of sys-net settings. When sys-net boots up, can you run `sudo journalctl -b ` in sys-net and look for any entries relating to networking devices. It may be that you need specific drivers for the NIC, so knowing what it is would be a help. -- I never presume to speak for the Qubes team. When I comment in the mailing lists I speak for myself. -- You received this message because you are subscribed to the Google Groups "qubes-users" group. To unsubscribe from this group and stop receiving emails from it, send an email to qubes-users+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/qubes-users/ZeO5oqfRsyO49pVY%40thirdeyesecurity.org.
Re: [qubes-users] time sync dysfunctional
On Tue, Feb 06, 2024 at 01:08:09PM +0100, 'haaber' via qubes-users wrote: > addendum: if I run "date" in a client VM it will give the right > timezone, but still has 3min of delay.. > > On 2/6/24 11:45, 'haaber' via qubes-users wrote: > > Hi, > > > > I am still on Q4.1 (no time to do a full install now). Since a few days, > > my time ran large out of sync, despite the swdate displaying normal > > functioning. I rebooted, I restarted swdate. Its log says: > > > > [INFO] date output: 10:44:44 > > > > (which is London time, but otherwise correct), my set-to-Berlin-time > > clock displays 10:42 which is 1h and 3min wrong. If it was 1h exactly, > > I'd guess a user-malconfig, but 3min ?? > > > > do you have some hints on that? > > > > Thank you, Bernhard > > Hi Bernhard My first thought was that this is a Whonix issue, but the fact that `date` has the same 3 min offset speaks against that. Let me get to a 4.1 box and I will see if I can help. Do you have locales set differently in qube from in dom0? What timezone is set in dom0? What in the qube? What in your Whonix gateway? -- I never presume to speak for the Qubes team. When I comment in the mailing lists I speak for myself. -- You received this message because you are subscribed to the Google Groups "qubes-users" group. To unsubscribe from this group and stop receiving emails from it, send an email to qubes-users+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/qubes-users/ZcJOtWudrPFmk8qe%40thirdeyesecurity.org.
Re: [qubes-users] split-ssh question
On Fri, Sep 08, 2023 at 08:10:44AM +0200, haaber wrote: > I tried to configure split-ssh according to the tutorial on qubes pages, > in its simple version (just agent, but no keepass integration). But now > ssh offers *all* my private keys to *all* servers, which is odd, but > more annoying, it usually breaks connections after 3 "false" public keys > ... > > Clearly, I did something wrong, but I do not understand well-enough what > I should change. Did some have/solve this problem already or have a > hint for me, please? Thank you! > I dont think you did anything wrong. I think what you are looking for is something like my split-ssh-agent - This allows you to have multiple keys, allocated as you will between different agents on the ssh back-end. >From each calling qube, you specify (in policy) what agent should be called, and this is passed through to the ssh back-end to serve up the appropriate keys. You can find it at https://github.com/unman/qubes-ssh-agent or a packaged version for easy installation at https://qubes.3isec.org/tasks.html If you dont use it, it should give you one idea of how you might go on. -- You received this message because you are subscribed to the Google Groups "qubes-users" group. To unsubscribe from this group and stop receiving emails from it, send an email to qubes-users+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/qubes-users/ZP3nIme3BRQK%2BktD%40thirdeyesecurity.org.
Re: [qubes-users] saltstack: detect the os within a running target/state.sls
On Thu, Aug 24, 2023 at 11:26:30AM +0200, lik...@gmx.de wrote:
> Hi!
>
> Running grains['os'] in a target returns always "Fedora" and grains['id']
> returns "dom0". For this reason I cannot branch in my state files for
> different os templates.
> Executing this test in such a targeted state.sls:
>
> test-grains-for-choosing-the-right-template:
> test.configurable_test_state:
> - name: "grains test"
> - changes: True
> - result: True
> - comment: {{ grains['os'] ~ ", " ~ grains['id'] ~ ", " ~
> grains['osfullname'] ~ ", " ~ grains['os_family'] }}
>
> returns
> grains['os']=Fedora, grains['os']=dom0, grains['osfullname']=Qubes,
> grains['osfamily']=RedHat
>
> Any ideas why this happens? How to branch correctly in a state file depending
> on the os of the template?
>
> Best, P!
>
When you use qubesctl it acts in the following order - dom0, templates,
template based qube. Unless you specifically exclude dom0, the state
will be applied to dom0.
You havent said what command you entered, which would have been useful,
but my guess is that you used `qubesctl state.apply ...`
If you want to target a template, then you should use:
`qubesctl --skip-dom0 --targets=LIST_OF_TARGETS .`
If you want a state file to be used BOTH for dom0 and templates, you can
use a "defensive" approach - there are examples of this at
http://github.com/unman/shaker
Use a jinja block like - {% if grains['nodename'] != 'dom0' %}
This will ensure that non-dom0 stuff gets correctly applied, while
making sure that those parts of the state dont get applied to dom0.
--
You received this message because you are subscribed to the Google Groups
"qubes-users" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to qubes-users+unsubscr...@googlegroups.com.
To view this discussion on the web visit
https://groups.google.com/d/msgid/qubes-users/ZOh%2Bxvf2ReSaLmeP%40thirdeyesecurity.org.
Re: [qubes-users] QubesIncoming folder in /tmp ??
On Fri, Jun 30, 2023 at 12:27:41PM +0200, haaber wrote: > Hi I was wondering if it would not me preferable (at least in some VM's) > to delocalise the QubesIncoming folder in /tmp to have it "cleaned up" > regularly. It's a pain to do so manually. Is there a problem doing so ? > What would be the cleanest way to do it? A symlink ?? thank you, Bernhard > I use this in rc.local: ``` mkdir /home/user/QubesIncoming chown user:user /home/user/QubesIncoming mkdir /tmp/QubesIncoming chown user:user /tmp/QubesIncoming mount --bind /tmp/QubesIncoming /home/user/QubesIncoming ``` I dont think the chown calls are needed, but I put them in , and have not removed them. Works as you would expect. -- You received this message because you are subscribed to the Google Groups "qubes-users" group. To unsubscribe from this group and stop receiving emails from it, send an email to qubes-users+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/qubes-users/ZJ9%2B%2BrugSSu6AW6W%40thirdeyesecurity.org.
Re: [qubes-users] How to make sys-firewall broadcast a local qube as the system-wide DNS server?
On Tue, Jun 06, 2023 at 01:24:18PM -0500, Leo28C wrote: > I managed to set up a pi-hole qube and make it my network's DNS > filtering/caching server. Ironically, it works flawlessly across my network > EXCEPT it completely breaks DNS for all other qubes in the same system. On > Debian-based qubes I figured out I can simply edit /etc/resolv.conf, while > making sure sys-firewall lets the two qubes talk to each other, as a > workaround. However this is a hacky per-qube solution and doesn't persist > across qube restarts. It would be nice to simply have sys-firewall relay > the information to all of its client qubes automatically. Any idea how to > do this? > > Thanks in advance! > You dont need to change the settings per qube at all. You haven't said *where* the pi-hole qube is located in your qubes network, or what the nature of the breakage is. I assume from what you say it is attached to sys-firewall. You can do this by editing the PR-QBS chain in nat table in sys-firewall. By default, this forwards all DNS traffic to 10.139.1.1 and 10.139.1.2 using dnat. Flush that chain and replace it with dnat rules to the IP address of your Pi-hole qube. You could do this in /rw/config/qubes-firewall-user-script or by script in /rw/config/qubes-firewall.d -- You received this message because you are subscribed to the Google Groups "qubes-users" group. To unsubscribe from this group and stop receiving emails from it, send an email to qubes-users+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/qubes-users/ZIHekYeyI0BY5uUa%40thirdeyesecurity.org.
Re: [qubes-users] Colourful prompt
On Thu, May 04, 2023 at 05:01:38AM -0700, Andrew David Wong wrote: > On 5/3/23 4:02 AM, Qubes wrote: > > I have noticed on Fedora, the cli prompt itself is not colourful although > > the rest of the output is. Is there a way to get the prompt itself in > > colour as well? The prompt on Debian is in colour, it makes it easier to > > find things when the prompt is in colour aswell. > > > > Since this is not a Qubes-specific question, you might have better luck > searching the web for how to do this in Fedora (or Linux in general) or > asking in a Fedora (or general Linux) venue. > I wonder if this *is* Qubes specific, as it is stated that the Debian prompt is in color. (Implicit, I think, is the suggestion that the color matches the window decorations.) OP - is that what you see? That the prompt is consistent with the window decoration set by Qubes? -- You received this message because you are subscribed to the Google Groups "qubes-users" group. To unsubscribe from this group and stop receiving emails from it, send an email to qubes-users+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/qubes-users/ZFOgEprkEoVo25%2Bv%40thirdeyesecurity.org.
Re: [qubes-users] Injecting configuration files into appVM when it's created/started for the first time
On Wed, May 03, 2023 at 04:19:00PM +, Qubes wrote: > > 'unman' via qubes-users wrote: > > On Wed, May 03, 2023 at 12:53:00PM +, Qubes wrote: > > > > > Is there a sane way to update existing `*.conf` files on VMs that are > > > already running? > > > Is there a not-so-labour-intensive way to solve this problem? > > > > Use salt - it's easy to apply to existing qubes, as well as template. > > You can (if you wish) store the config file whole, or just the changes > > that you want to make, as part of the install. > > It also has the advantage of being self documenting. > > > I have looked over salt, albeit briefly, but it definitely does not look > like something that someone with no knowledge of salt can just jump in and > use. You have mentioned this a lot so perhaps the best person here to ask > is you. Can you maybe recommend a salt for 'dummies' guide? > I have some notes at https://github.com/unman/notes which take you through simple steps with many examples of using salt in Qubes. -- You received this message because you are subscribed to the Google Groups "qubes-users" group. To unsubscribe from this group and stop receiving emails from it, send an email to qubes-users+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/qubes-users/ZFMc9rIv4VwnBPg7%40thirdeyesecurity.org.
Re: [qubes-users] Injecting configuration files into appVM when it's created/started for the first time
On Wed, May 03, 2023 at 12:53:00PM +, Qubes wrote: > Is there a sane way to update existing `*.conf` files on VMs that are > already running? > Is there a not-so-labour-intensive way to solve this problem? Use salt - it's easy to apply to existing qubes, as well as template. You can (if you wish) store the config file whole, or just the changes that you want to make, as part of the install. It also has the advantage of being self documenting. -- You received this message because you are subscribed to the Google Groups "qubes-users" group. To unsubscribe from this group and stop receiving emails from it, send an email to qubes-users+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/qubes-users/ZFKNmZMMJjV2eD40%40thirdeyesecurity.org.
Re: [qubes-users] Updating via a wireguard connection
On Fri, Apr 28, 2023 at 11:58:55AM -0700, Jeremy Hansen wrote: > I would like to configure Qubes to do its updates via a connection to a > wireguard service I have set up. > > I understand how to set up a wireguard enabled template and a qubes based on > that template following this: > > https://github.com/hkbakke/qubes-wireguard > > which works great, but I would like to force package updates to also use a > wireguard connection. I???m not quite sure what to alter to do this. Any help > would be much appreciated. > > -jeremy > The default is for updates to run in sys-net. You need to change this by changing the policy - look in `/etc/qubes/policy.d/90-default.policy` for the `qubes.UpdatesProxy` lines, and then create a new policy in `/etc/qubes/policy.d/30-user.policy` like this: `qubes.UpdatesProxy * @type:TemplateVM @default allow target=QUBE` where QUBE is the name of the qube you want to use. If you use Whonix you will need to copy the relevant Whonix lines also. Set the netvm for QUBE to be your wireguard qube. -- You received this message because you are subscribed to the Google Groups "qubes-users" group. To unsubscribe from this group and stop receiving emails from it, send an email to qubes-users+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/qubes-users/ZEzwfyp8Whgzsfcl%40thirdeyesecurity.org.
Re: [qubes-users] Template for X?
On Sat, Apr 29, 2023 at 04:53:10PM +0800, Sandy Harris wrote: [quote] Is there a template to make a qube that just runs as an X terminal? [/quote] Have you tried a minimal template? -- You received this message because you are subscribed to the Google Groups "qubes-users" group. To unsubscribe from this group and stop receiving emails from it, send an email to qubes-users+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/qubes-users/ZEzuT6GWcmBSk%2BCi%40thirdeyesecurity.org.
Re: [qubes-users] Data recovery -- thin provisioned LVM metadata (?) problem
On Tue, Apr 25, 2023 at 08:19:48AM +0200, haaber wrote: > Dear all, > > I had a lethally bad hardware failure on computer. Since I had to buy a > new machine this took a while, now I try to save some data: the old SSD > is attached to a brand-new qubes via usb adapter. I started > > sudo pvscan and sudo vgscan --mknodes and sudo vgchange -ay as > manual says. > > unexpected output: > > PV /dev/mapper/OLDSSD VG qubes_dom0 lvm2 [238.27 GiB / <15.79 > GiB free] > Total: 1 [238.27 GiB] / in use: 1 [238.27 GiB] / in no VG: 0 [0 ] > Found volume group "qubes_dom0" using metadata type lvm2 > Check of pool qubes_dom0/pool00 failed (status:1). Manual repair > required! > > 1 logical volume(s) in volume group "qubes_dom0" now active > > then I consulted dr. google for help, and found little help. This one > > https://mellowhost.com/billing/index.php?rp=/knowledgebase/65/How-to-Repair-a-lvm-thin-pool.html > > suggested to deactivate volumed so that a repair can work. Only swap was > active, I deactivated it. But repair does not work: > > lvconvert --repair qubes_dom0/pool00 > terminate called after throwing an instance of 'std::runtime_error' > what(): transaction_manager::new_block() couldn't allocate new block > Child 21255 exited abnormally > Repair of thin metadata volume of thin pool qubes_dom0/pool00 failed > (status:-1). Manual repair required! > > > So now I am struck and ask for help! This is not purely qubes-related, I > known, but I hope to find competent help within the community. > > > cheers, Bernhard > Hi Bernhard Havent seen you for a while. Nice to see you back. I've been able to fix this in the past by deleting snapshots - I'm not sure if this will work for you. If I were you I would take a copy of the SSD with dd, and then start to prune - what happens if you use lvremove against some of the larger snapshots? unman -- You received this message because you are subscribed to the Google Groups "qubes-users" group. To unsubscribe from this group and stop receiving emails from it, send an email to qubes-users+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/qubes-users/ZEfjwfZ7zXBywyef%40thirdeyesecurity.org.
Re: [qubes-users] Modifying /etc/hosts in dispVM
On Thu, Apr 20, 2023 at 11:29:08AM +, Rusty Bird wrote: [quote] 'host' isn't suitable for testing this, because it never looks at the [/quote] Right - neither are most of the *other* DNS utilities - ping should do. Or `getent hosts ...` -- You received this message because you are subscribed to the Google Groups "qubes-users" group. To unsubscribe from this group and stop receiving emails from it, send an email to qubes-users+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/qubes-users/ZEEswfwmKYSuiE4w%40thirdeyesecurity.org.
Re: [qubes-users] Modifying /etc/hosts in dispVM
On Wed, Apr 19, 2023 at 07:06:19AM -0700, john.e...@gmail.com wrote: > I haven't been able to figure out how I can modify /etc/hosts in a dispVM > so that my entry (such as 10.1.1.1 myhost.example.commyhost) will be > used instead of DNS. > > I'm trying to direct my traffic to a different host than the one listed in > DNS. > > Anyone know an easy fix to this? Thanks. > It's a disposable - you need to set the change in the disposable template. Add this to /rw/config/rc.local in the disposable template: echo "10.1.1.1 myhost.example.com" >> /etc/hosts That will take effect in the disposable template, and in every disposable that uses it. I use this often because I block DNS for many qubes, provide hosts entries, and whitelist those IPs. -- You received this message because you are subscribed to the Google Groups "qubes-users" group. To unsubscribe from this group and stop receiving emails from it, send an email to qubes-users+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/qubes-users/ZEAGmG0Ql3wFocZf%40thirdeyesecurity.org.
Re: [qubes-users] dependency problem after upgrading standalone debian 11 VM
On Fri, Apr 14, 2023 at 04:10:29PM +0200, qubes-li...@riseup.net wrote: > Hi uman, > > thanks for your reply. > > 'unman' via qubes-users: > > Exactly this issue arose on GitHub - it is, as you say, because you did > > not update the qubes repository definition in timely way. > > You can read the issue > > [here](https://github.com/qubesos/qubes-issues/issues/7865) > > > The resolution is to follow the steps in the upgrade script - courtesy > > of Marek: > > ``` > > The source of the problem is that in R4.1 we actually stopped shipping own > > duplicated xen packages, and are relying on those from official Debian > > repositories. But the upgrade path requires manual step because of that. > > The in-place R4.0 -> R4.1 upgrade tool handle that automatically, but in > > case of manual upgrade, see this part: > > https://github.com/QubesOS/qubes-dist-upgrade/blob/release4.0/scripts/upgrade-template-standalone.sh#L37-L72 > > ``` > > Yes I know about this github ticket, I mentioned in my last email, but > I have the impression that these step can not be used _after_ > running 'apt update; apt upgrade; apt dist-upgrade' anymore - which is the > situation I'm in. > > Is there also a way to recover a system after the 'apt upgrade' step happened > already? > I'd probably be rolling back most of your recent changes, and starting again, after making sure that I have a decent backup of the qube in its current state. You need to roll back those packages, and -f should work for the install. I have some old templates hanging about - if you can wait until tomorrow I'll pull one and work through the process in the morning. -- You received this message because you are subscribed to the Google Groups "qubes-users" group. To unsubscribe from this group and stop receiving emails from it, send an email to qubes-users+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/qubes-users/ZDltBO75pErMxI/A%40thirdeyesecurity.org.
Re: [qubes-users] dependency problem after upgrading standalone debian 11 VM
Exactly this issue arose on GitHub - it is, as you say, because you did not update the qubes repository definition in timely way. You can read the issue [here](https://github.com/qubesos/qubes-issues/issues/7865) The resolution is to follow the steps in the upgrade script - courtesy of Marek: ``` The source of the problem is that in R4.1 we actually stopped shipping own duplicated xen packages, and are relying on those from official Debian repositories. But the upgrade path requires manual step because of that. The in-place R4.0 -> R4.1 upgrade tool handle that automatically, but in case of manual upgrade, see this part: https://github.com/QubesOS/qubes-dist-upgrade/blob/release4.0/scripts/upgrade-template-standalone.sh#L37-L72 ``` -- You received this message because you are subscribed to the Google Groups "qubes-users" group. To unsubscribe from this group and stop receiving emails from it, send an email to qubes-users+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/qubes-users/ZDlNncRfNAH//fIE%40thirdeyesecurity.org.
Re: [qubes-users] Kali Linux Purple - Defense
On Tue, Apr 04, 2023 at 10:11:19PM -0700, Foilsurf wrote: > Hello, > which of the out of the Box Defense features of the new *Kali Linux Purple*, > would be very nice to have also in *QubesOS *to raise the defense bar? (the > attacks also get every day harder...) > Kind Regards > I see that they emphasize defensive tools - mainly scanners, and IDS - but is there yet detail on configuration features? I havent yet seen that. Also, there's no sign that they will be moving from Debian testing. -- You received this message because you are subscribed to the Google Groups "qubes-users" group. To unsubscribe from this group and stop receiving emails from it, send an email to qubes-users+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/qubes-users/ZC2DkxvwJhiYiPvE%40thirdeyesecurity.org.
Re: [qubes-users] How Qubes handles the start of services
On Mon, Mar 27, 2023 at 06:33:26PM +0200, r.wiesb...@web.de wrote: > Hi uman, > > that was the reference in qubes-doc that I found before and that I could > not find today when I was writing this email. However, it does not > explain what the advantage of this two-switch-model is compared to just > run the services defined in the per-qube services tab/setting without > the dependence on being enabled in the template. > That approach would render adding support for [any generic] systemd > service not only "pretty simple" but would make every systemd service > compatible "by design". I think that a generic systemd service is already compatible by design:if you install such a service and enable it in the template it will be enabled in the qubes using that template. Is that not so? The current system provides a simple condition that gives granular control over services on a per qube basis. The same control can be achieved by *disabling* the service in the template, and having a switch that enables the service and starts it in the qube. I do this myself in some cases. (From dom0 with qvm-run, or with entries in rc.local, e.g.) Both approaches require some action in the template as well as action in the qube. So both are "two-switch". The current mechanism provides a dead mans handle but allows services to start at an early stage. You are not obliged to use it for other services. -- You received this message because you are subscribed to the Google Groups "qubes-users" group. To unsubscribe from this group and stop receiving emails from it, send an email to qubes-users+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/qubes-users/ZCL4GLiMKwI%2B2btY%40thirdeyesecurity.org.
Re: [qubes-users] How Qubes handles the start of services
On Mon, Mar 27, 2023 at 03:48:15PM +0200, r.wiesb...@web.de wrote: > Hi there, > > every VM/qube has a "services" tab in its settings window. It seems like > Qubes is designed in a manner that requires two switches for a service: > it needs to be enabled in the template *and* requires an entry in > "services" tab. > > My expectation was that when selected in the "services" tab, qubesrc (or > any other instance) will just start the corresponding service in the VM. > During troubleshooting I found out that it is designed as above, but I > could not find the reason for this design decision. > > At least the "services tab" should have a red text warning that it is > required to enable the service in the template as well in order to not > confuse users the way it confused myself. > > > best, > Ron > This is a long standing design. The process is explained at https://www.qubes-os.org/doc/qubes-service/ The text on the service tab is unclear - it *does* say that the service will be turned on. I've raised an issue to have this clarified. -- You received this message because you are subscribed to the Google Groups "qubes-users" group. To unsubscribe from this group and stop receiving emails from it, send an email to qubes-users+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/qubes-users/ZCGwR5nTbOD/kLIl%40thirdeyesecurity.org.
Re: [qubes-users] Odd behavior wile running two separate Whonix gateways
On Fri, Mar 24, 2023 at 04:23:48AM +, tiesta_symonne61 via qubes-users wrote: > I have two Whonix gateways, the default sys-whonix and a sys-whonix-clone. > Both are attached to different net vm's. > > The problem is that all qubes that have sys-whonix-clone as its net vm > show up under sys-whonix's tray icon, not sys-whonix-clone's. I'm pretty > sure the actual traffic is being routed through the correct gateways, but > my only metric for knowing that is looking at CPU usage while stressing > the connection and making sure the correct chain of net vm's light up. > [quote] Is this just a GUI quirk, or should I worry about actual risk of traffic getting mixed between the two gateway qubes? [/quote] It sounds like a GUI bug - you could check what is happening by running a sniffer on sys-whonix, or by examining counters on the firewall rules. I don't have whonix installed to e able to tell you if the tools for this are installed. (You could try running `iptables -L -nv -t nat` and seeing if the counts for one of the errant qubes increments. Report back.) -- You received this message because you are subscribed to the Google Groups "qubes-users" group. To unsubscribe from this group and stop receiving emails from it, send an email to qubes-users+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/qubes-users/ZB2cU6he45EzVAtq%40thirdeyesecurity.org.
Re: [qubes-users] 'qvm-copy' and 'qvm-copy-to-vm' in AppVM
qvm-copy-to-vm is deprecated and will be removed. -- You received this message because you are subscribed to the Google Groups "qubes-users" group. To unsubscribe from this group and stop receiving emails from it, send an email to qubes-users+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/qubes-users/ZB2bCFm2zx1DMg2v%40thirdeyesecurity.org.
Re: [qubes-users] Shutdown Delay
On Wed, Dec 28, 2022 at 11:00:18AM +0100, Ulrich Windl wrote: > Hi! > > Am I the only one that sees extra shutdown delays? > It seems that everything is unmounted, but still thing hang; unsure what that > is. See attachment. > What surprises me is that crypto seems to be stopped before unmount. > > Regards, > Ulrich > No, I often see excessive shutdown delays. -- You received this message because you are subscribed to the Google Groups "qubes-users" group. To unsubscribe from this group and stop receiving emails from it, send an email to qubes-users+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/qubes-users/Y7RFxd4RbhGW9VSQ%40thirdeyesecurity.org.
Re: [qubes-users] No editor at all in 'fedora-36-minimal' template?
On Sun, Oct 09, 2022 at 05:34:50AM -0700, Viktor Ransmayr wrote: > Is it correct, that this template does not provide any editor 'package' at > all? No, there's nano -- You received this message because you are subscribed to the Google Groups "qubes-users" group. To unsubscribe from this group and stop receiving emails from it, send an email to qubes-users+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/qubes-users/Y0LH3cSkr4bcm7CS%40thirdeyesecurity.org.
Re: [qubes-users] firefox-esr and brave-browser work, but firefox, nautilus, thunar, gnome-terminal, xterm do not
On Wed, Aug 24, 2022 at 07:12:45PM -0700, Andrew David Wong wrote: > On 8/24/22 2:31 PM, Franz wrote: > > Hello, > > the following command is intended to run an application in a new DVM: > > > > qvm-run --dispvm=debian-11-dvm --service qubes.StartApp+ > > > > If in place of I put firefox-esr or brave-browser it works, the > > new DVM is opened and the application works as expected. > > > > But if in place of I put firefox, nautilus, thunar, > > gnome-terminal, xterm the DVM starts, but immediately after closes with > > error: > > command failed with code:1 > > > > Any idea to solve it or is it just a bug? > > > > > > > > firefox-esr and brave-browser work, but firefox, nautilus, thunar, > > gnome-terminal, xterm do not > > > > You might be missing .desktop files or something for the ones that aren't > working. That seems to be a common problem. > > I prefer the simplicity and reliability of this type of command: > > qvm-run --dispvm=debian-11-dvm > > E.g.: > > qvm-run --dispvm=debian-11-dvm nautilus > In Debian, the desktop file is firefox-esr.desktop. The application is available using either firefox or firefox-esr. When you use the --service form of qvm-run it references the desktop files, as Andrew said.(The Debian package is also called firefox-esr, and `firefox` is a shell script that calls `firefox-esr`) In Debian, the desktop file for xterm is `debian-xterm.desktop`, so that's how you must address it if you use the --service form. Nautilus is org.gnome.Nautilus.Desktop etc. Some of the examples you gave have a different root cause, because of the way that those applications work. For example, gnome-terminal will call the gnome-terminal server and spawn an instance of the terminal. Because of the way that disposables work, when that first call completes, the disposable shuts down, so you never see a terminal window. Qubes provides qubes-run-gnome-terminal to help with this. -- You received this message because you are subscribed to the Google Groups "qubes-users" group. To unsubscribe from this group and stop receiving emails from it, send an email to qubes-users+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/qubes-users/YweGRH4YV%2BrCBG7J%40thirdeyesecurity.org.
Re: [qubes-users] Qubes Contrib repository
On Sat, Aug 13, 2022 at 10:02:15PM +0200, Qubes wrote: > Qubes wrote: > > I guess one way to see what is available in the contrib repo is to look > > on [Github][1], but is there a way to list the available packages in the > > contrib repo from cli? > > > > Assuming that one has already added the contrib repo, > > > > ``` > > sudo qubes-dom0-update qubes-repo-contrib > > ``` > > > > [1]: (https://github.com/QubesOS/qubes-issues/issues/7389) > > > Oops, wrong URL provided, > > > [1]: https://github.com/QubesOS-contrib > qubes-dom0-update --repo=qubes-contrib-dom0-r4.1-current --action=list -- You received this message because you are subscribed to the Google Groups "qubes-users" group. To unsubscribe from this group and stop receiving emails from it, send an email to qubes-users+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/qubes-users/YwJBU2L0YStzrudJ%40thirdeyesecurity.org.
Re: [qubes-users] Re: Problems with Timesynchronization
> > Can you please comment on how it is possible, that > "ConditionPathExists=/var/run/qubes-service/clocksync was not met" - and - > ideally, how to resolve that issue. > That suggests that you do not have the clocksync service enabled. Set it with `qvm-service --enable QUBE clocksync` or `qvm-features QUBE service.clocksync 1` -- You received this message because you are subscribed to the Google Groups "qubes-users" group. To unsubscribe from this group and stop receiving emails from it, send an email to qubes-users+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/qubes-users/YuZmeyeQ/YQ9JZb4%40thirdeyesecurity.org.
Re: [qubes-users] qvm-firewall command error
On Wed, Jul 27, 2022 at 03:59:03PM -0700, Howard Chen wrote: > Currently, I am configuring my NetworkIT qube firewall with the > qvm-firewall command in dom0 terminal. However, when I entered this, it > showed this following error: > > [Howard@dom0 ~]$ qvm-firewall NetworkIT add dsthost 10.137.0.5 You havent given a valid rule: parameters are wrong and no action given. Look at the manpage and qvm-firewall --help. qvm-firewall NetworkIT add accept 10.137.0.5 OR qvm-firewall NetworkIT add accept match dsthost=10.137.0.5/32 -- You received this message because you are subscribed to the Google Groups "qubes-users" group. To unsubscribe from this group and stop receiving emails from it, send an email to qubes-users+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/qubes-users/YuPSDNU3idfZ7s8C%40thirdeyesecurity.org.
Re: [qubes-users] qubes core agent networking iso building help
On Tue, Jul 19, 2022 at 09:28:00AM -0700, Howard Chen wrote: > Thanks, Unman. This will take me about 18 to 19 months to finish and > publish if I have the right tools that I need and the codes probabilities > for that to happen. > On Tuesday, July 19, 2022 at 4:08:06 AM UTC-7 unman wrote: > > > On Mon, Jul 11, 2022 at 11:47:19AM -0700, Howard Chen wrote: > > > I need help to build the qubes core agent tools for the new OS that > > called > > > LinuxFX. Here is the story. > > > > > > I stumped across the YT for other Linux OS that functions similar to > > > Windows. This OS that was introduced to me by a YouTuber goes by "Linux > > For > > > Everyone" with a video called "This Linux OS Looks EXACTLY Like Windows > > > 10!" This video talks about this OS that I am working with and will > > > implemented into Qubes if I can do it. The question is: How to create an > > > ISO file in qubes? > > > > > I'm not clear what you are asking. > > Do you want to build the core agent tools? Read the docs on > > qubes-builder. LinuxFX is based on Ubuntu so you can probably use the > > Ubuntu tools as is. > > Do you want to build a template? Treat it as a flavor of Ubuntu, so you > > build (e.g) focal+linuxfx. > > > > If you want to create a Qubes based on LinuxFX instead of Fedora, then > > that's far more difficult. You'll need to build all the components for > > Ubuntu. > > An alternative would be to use Fedora as dom0, and try to implement > > LinuxFX as sys-gui. > > Whatever your aim you should read the docs on building. > > I still dont know what you are trying to do. -- You received this message because you are subscribed to the Google Groups "qubes-users" group. To unsubscribe from this group and stop receiving emails from it, send an email to qubes-users+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/qubes-users/YtfkfM2CYHscJ942%40thirdeyesecurity.org.
Re: [qubes-users] KDE on 4.1
On Tue, Jul 19, 2022 at 01:26:13PM +0200, Qubes wrote: > Qubes wrote: > > 'unman' via qubes-users wrote: > > > On Tue, Jul 19, 2022 at 08:41:40AM +0200, Qubes wrote: > > > > The procedure to install KDE in 4.1 doesn't seem to work, is > > > > that expected > > > > behavior? > > > > > > Yes, the group isn't present. > > > qubes-dom0-update kde-settings-qubes > > > > > > > Is this the way of installing KDE now which means the documentation must > > be updated or is this just a workaround? > > > > Also, would the correct procedure to remove KDE still be as per the > documentation, > > "sudo dnf remove kdelibs plasma-workspace" dnf remove kde-settings-qubes -- You received this message because you are subscribed to the Google Groups "qubes-users" group. To unsubscribe from this group and stop receiving emails from it, send an email to qubes-users+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/qubes-users/YtaVV8RIYtSiOB4R%40thirdeyesecurity.org.
Re: [qubes-users] KDE on 4.1
On Tue, Jul 19, 2022 at 11:49:04AM +0200, Qubes wrote: > 'unman' via qubes-users wrote: > > On Tue, Jul 19, 2022 at 08:41:40AM +0200, Qubes wrote: > > > The procedure to install KDE in 4.1 doesn't seem to work, is that expected > > > behavior? > > > > Yes, the group isn't present. > > qubes-dom0-update kde-settings-qubes > > > > Is this the way of installing KDE now which means the documentation must be > updated or is this just a workaround? > The documentation is in transition from 4.0 to 4.1 This will be in the update. -- You received this message because you are subscribed to the Google Groups "qubes-users" group. To unsubscribe from this group and stop receiving emails from it, send an email to qubes-users+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/qubes-users/YtaUVZo/UiNn99fe%40thirdeyesecurity.org.
Re: [qubes-users] qubes core agent networking iso building help
On Mon, Jul 11, 2022 at 11:47:19AM -0700, Howard Chen wrote: > I need help to build the qubes core agent tools for the new OS that called > LinuxFX. Here is the story. > > I stumped across the YT for other Linux OS that functions similar to > Windows. This OS that was introduced to me by a YouTuber goes by "Linux For > Everyone" with a video called "This Linux OS Looks EXACTLY Like Windows > 10!" This video talks about this OS that I am working with and will > implemented into Qubes if I can do it. The question is: How to create an > ISO file in qubes? > I'm not clear what you are asking. Do you want to build the core agent tools? Read the docs on qubes-builder. LinuxFX is based on Ubuntu so you can probably use the Ubuntu tools as is. Do you want to build a template? Treat it as a flavor of Ubuntu, so you build (e.g) focal+linuxfx. If you want to create a Qubes based on LinuxFX instead of Fedora, then that's far more difficult. You'll need to build all the components for Ubuntu. An alternative would be to use Fedora as dom0, and try to implement LinuxFX as sys-gui. Whatever your aim you should read the docs on building. -- You received this message because you are subscribed to the Google Groups "qubes-users" group. To unsubscribe from this group and stop receiving emails from it, send an email to qubes-users+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/qubes-users/YtaQkhcrfP9geurm%40thirdeyesecurity.org.
Re: [qubes-users] KDE on 4.1
On Tue, Jul 19, 2022 at 08:41:40AM +0200, Qubes wrote: > The procedure to install KDE in 4.1 doesn't seem to work, is that expected > behavior? Yes, the group isn't present. qubes-dom0-update kde-settings-qubes -- You received this message because you are subscribed to the Google Groups "qubes-users" group. To unsubscribe from this group and stop receiving emails from it, send an email to qubes-users+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/qubes-users/YtZ9X8dYhbJrwGxe%40thirdeyesecurity.org.
Re: [qubes-users] VM initial memory
On Wed, Jul 13, 2022 at 05:28:01PM +0200, Qubes wrote: > Hi > > I am trying to figure out the significance of the "Initial memory" setting > of a VM. Does it make any difference? For example VM A and B. A is > configured with 500 MB initial memory and 2000 MB Max memory. VM B is > configured with 1000 MB Inintial memory and also 2000 MB Max memory. Is > there a situation where the initial memory will play a role? > > I did once have a problem where, I think a think at the time it was a Fedora > 32 template that did not boot when its initial memory was set at 200 MB. > Other than start up problems however, does this setting affect anything in > any way for one to make it a genuine consideration? > I think that at present a qube will start with maxmem and then balloon down to initial memory. If memory is set too low the qube wont start, as you say. I don't think that memory allocated will drop below "Initial memory", so if you are tight on RAM it makes sense to reduce it. -- You received this message because you are subscribed to the Google Groups "qubes-users" group. To unsubscribe from this group and stop receiving emails from it, send an email to qubes-users+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/qubes-users/YtKuABN6H3K4Zbc0%40thirdeyesecurity.org.
Re: [qubes-users] Onion site and repos are down
I am advised that the onion server is back online unman -- You received this message because you are subscribed to the Google Groups "qubes-users" group. To unsubscribe from this group and stop receiving emails from it, send an email to qubes-users+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/qubes-users/YtCqc8o85LjB6Ge9%40thirdeyesecurity.org.
[qubes-users] Onion site and repos are down
I am advised that there is a hardware fault, and the onion site is down. We're working on it. -- You received this message because you are subscribed to the Google Groups "qubes-users" group. To unsubscribe from this group and stop receiving emails from it, send an email to qubes-users+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/qubes-users/Ys4ONaNdHTxlzK5v%40thirdeyesecurity.org.
Re: [qubes-users] Using the second os on the (dual-booted) system as a VM
On Mon, Jul 11, 2022 at 05:14:05AM -0700, MUT wrote: > I want to try creating maybe a standalone VM that would mount a partition > on my hard drive which has a seperate os installed on it as its root, and > use that as a VM. Effectively that would let you use the second OS you have > installed on a computer besides Qubes as a VM in qubes. I searched around > the web to see if someone has done it, but couldn't find anything. > > I'd be very thankful for any help or advice regarding that, will post some > updates after I actually try it. > I'm surprised you couldn't find anything on this. You want to create a block device using the other partition and use it in place of the standalone root. You can customise the standalone definition or do some jiggery pokery to get it running. I hacked about with this and will look out my notes. -- You received this message because you are subscribed to the Google Groups "qubes-users" group. To unsubscribe from this group and stop receiving emails from it, send an email to qubes-users+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/qubes-users/YsxPMvMBBOtJ%2B3oU%40thirdeyesecurity.org.
Re: [qubes-users] Fedora 36 templates available
On Tue, Jun 28, 2022 at 03:42:22AM +, Metatron wrote: > On Mon, Jun 27, 2022 at 07:41:57PM -0700, Andrew David Wong wrote: > > Dear Qubes Community, > > > > New Fedora 36 templates are now available for Qubes 4.1! > > Is anyone else having this problem: > # sudo qubes-dom0-update qubes-template-fedora-36 > Redirecting to 'qvm-template install fedora-36' > Downloading 'qubes-template-fedora-36-0:4.0.6-202205270243'... > qubes-template-fedora-36-0:4.0.6-202205270243: 0%| | 0.00/1.72G > [00:00 qubes-template-fedora-36-0:4.0.6-202205270243: 0%| | 0.00/1.72G > [00:01 ERROR: [Errno 2] No such file or directory: > '/root/.cache/qvm-template/tmps3hgqf8e/qubes-template-fedora-36-0:4.0.6-202205270243.rpm.UNTRUSTED' > > Thanks! > It was an issue, but has probably already been resolved by time. -- You received this message because you are subscribed to the Google Groups "qubes-users" group. To unsubscribe from this group and stop receiving emails from it, send an email to qubes-users+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/qubes-users/Yr3FegxfDms0k%2Bb5%40thirdeyesecurity.org.
Re: [qubes-users] Problems with announced Fedora 35 templates
On Sun, Jun 12, 2022 at 01:44:41AM -0700, Viktor Ransmayr wrote: > Hello Steve, > > stevenlc...@gmail.com schrieb am Samstag, 11. Juni 2022 um 17:52:19 UTC+2: > > > > > It looks to me that your current sys-firewall template is not up to date > > for your current R4.1 version, or just broken. If you have any other > > templates on your system (e.g. debian-11, fc35-minimal, fc35-xfce ) you > > might want to try switching sys-firewall to something else and then try to > > use qvm-template to download a working template of the f35 flavor. > > > > Your suggestion was obviously the next step I tried. - Unfortunately again > it did not improve anything :-( > > Here are my logs & notes: > > ### > > Change the template for 'sys-firewall' from 'fedora-34' to 'debian-11'. > > * Close all Study-VMs - and - close the affected 'sys-whonix' VM ... > * Perform the template change ... > * Try now to download the new 'fedora-35' templates - Not OK - See > "Log-001". > > ### Log-001 > > [vr@dom0 ~]$ > [vr@dom0 ~]$ sudo qubes-dom0-update qubes-template-fedora-35 > Redirecting to 'qvm-template install fedora-35' > [Qrexec] /bin/sh: 0: cannot open /etc/qubes-rpc/qubes.TemplateSearch: > No such file > ERROR: qrexec call 'qubes.TemplateSearch' failed. > [vr@dom0 ~]$ > [vr@dom0 ~]$ > [vr@dom0 ~]$ sudo qubes-dom0-update --clean --console --show-output > Using sys-firewall as UpdateVM to download updates for Dom0; this may > take some time... > 0 files removed > Unable to detect release version (use '--releasever' to specify release > version) > Fedora 32 - x86_64 - Updates6.3 MB/s | 35 MB > 00:05 > Fedora 32 - x86_64 6.3 MB/s | 63 MB > 00:09 > Qubes Dom0 Repository (updates) 572 kB/s | 3.8 MB > 00:06 > Last metadata expiration check: 0:00:05 ago on Sun Jun 12 09:48:13 2022. > Dependencies resolved. > Nothing to do. > Complete! > No packages downloaded > No updates available > [vr@dom0 ~]$ > > ### > > Thanks a lot for your support in trying to find a solution for my problem. > > With kind regards, > > Viktor > Hi Viktor My vanilla debian-11 template *does* have /etc/qubes-rpc/qubes.TemplateSearch. That file is provided by qubes-core-agent-dom0-updates. I currently have version 4.1.36-1 I suggest you make sure that you have that package installed and that your debian-11 template is fully updated. That should resolve the problem. unman -- You received this message because you are subscribed to the Google Groups "qubes-users" group. To unsubscribe from this group and stop receiving emails from it, send an email to qubes-users+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/qubes-users/YqXgxrBlONIjjy%2B9%40thirdeyesecurity.org.
Re: [qubes-users] qubes update -- how to hold an old kernel ??
On Fri, Jun 10, 2022 at 08:55:41AM +0200, haaber wrote: > Recent QSB made me run the qubes-update. Regrettably, it wants to remove > a kernel version that I need to hold (in case of foreseeable problems > with newer ones). How can I freeze that older version and forbid its > uninstall? > > best, Bernhard > Hi Bernhard There are a number of things you can do: the simplest - Increase the number of kernel packages that are retained: In /etc/dnf/dnf.conf change installonly_limit=3 to some higher number. Then manually delete kernel packages that are intermediate. That way you keep the working version *and* get the updates so you can try them as they come in. There used to be a plugin to lock dnf updates to a specific version, but I think that disappeared a few years ago. You can try `dnf mark install kernel-VERSION` which *should* hold that package version on the system, but that hasn't always worked for me. There is another simple approach - run the update while booted in to the kernel you want to hold. dnf wont remove the running kernel, and will uninstall newer versions to stay within the installonly_limit you have set. Some combination of these should allow you to hold (some) older kernel version while still allowing you to try updated kernels. unman -- You received this message because you are subscribed to the Google Groups "qubes-users" group. To unsubscribe from this group and stop receiving emails from it, send an email to qubes-users+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/qubes-users/YqXeEJ06Mr%2BCXl51%40thirdeyesecurity.org.
Re: [qubes-users] Failing Salt code: out of ideas and wrong error
On Tue, May 24, 2022 at 11:54:27PM +0200, 'Johannes Graumann' via qubes-users
wrote:
> Can any one point me to why the following fails? I have been banging my
> head against this for a while ...
>
> --- SNIP ---
> create bind dirs config file:
> file.managed:
> - name: /rw/config/qubes-bind-dirs.d/50_user.conf
> - makedirs: True
> - mode: 644
> - dir_mode: 755
>
> {% set binddirs = ['/usr/local'] %}
>
> {% for binddir in binddirs %}
> configure '{{ binddir }}' to be persistent:
> file.replace:
> - name: /rw/config/qubes-bind-dirs.d/50_user.conf
> - pattern: "^binds+=( '{{ binddir }}' )$"
> - repl: "binds+=( '{{ binddir }}' )"
> - append_if_not_found: True
> {% endfor %}
> --- SNIP ---
>
> The corresponding error ("State 'create bind dirs config file' in SLS
> 'custom_dom0.sys-vpn-mpihlr_assert_vpn_setup' is not formed as a list")
> is a complete red herring, as the so called first part by itself works
> just fine and only fails when I add the latter (jinja) part ...
>
> How do I properly deal with the single quotes in `pattern` and `repl`?
>
> Thanks for any pointers.
>
> Sincerely, Joh
>
>
Hi Joh
Change the closing tag on the for statement to "-%}"
This is, I think, salt specific - according to the jinja specs it will remove
whitespace
Your use of single quotes in pattern and repl will be fine.
A simpler (and lazier) formulation would use file.append:
{% for binddir in binddirs %}
configure '{{ binddir }}' to be persistent:
file.append:
- name: /rw/config/qubes-bind-dirs.d/50_user.conf
- text: "binds+=( '{{ binddir }}' )"
- makedirs: True
{% endfor %}
You can drop the explicit file.managed in this case.
unman
--
I **never** presume to speak for the Qubes team.
When I comment in the Forum or in the mailing lists I speak for myself.
--
You received this message because you are subscribed to the Google Groups
"qubes-users" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to qubes-users+unsubscr...@googlegroups.com.
To view this discussion on the web visit
https://groups.google.com/d/msgid/qubes-users/Yo44Q9qWm3fcpctZ%40thirdeyesecurity.org.
