[qubes-users] Re: Can't install Qubes, Rebooting after loading initrd.img

2018-02-21 Thread Daniil .Travnikov
четверг, 22 февраля 2018 г., 4:18:15 UTC+3 пользователь Tim W написал:
> Need more info for.people to help you.  Your lqptop hardware make model 
> processor is it one off the qubes list that shows its supported.  What is the 
> graphic card?  Mnay blackscrn flicker issues are video card related i.e. 
> nvidia amd.

Thank you for your asking.

At first I want to tell, that this is a server configuration, not laptop or 
home PC.


My configuration is:
---
Intel® Server Board S5520HC
(https://ark.intel.com/products/36599/Intel-Server-Board-S5520HC)

System BIOS Version S5500.86B.01.00.0064
updated to the latest Build Date 05/05/2014

Total Memory 16384 MB

CPU 1 and CPU2 - Intel (R) Xeon (R) E5606 2.13GHz

Screen about Virtualization: https://prnt.sc/ii5n4y

About graphic card, actually I have not any discret card, my monitor working 
trhough VGA which has not high resolution.

-- 
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 post to this group, send email to qubes-users@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/qubes-users/2f43c58b-31c6-4b7e-b0fd-28d05e362a05%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.


[qubes-users] Re: Can't install Qubes, Rebooting after loading initrd.img

2018-02-21 Thread Daniil .Travnikov
среда, 21 февраля 2018 г., 23:39:50 UTC+3 пользователь Yuraeitha написал:
> On Wednesday, February 21, 2018 at 9:43:17 AM UTC+1, Daniil .Travnikov wrote:
> > I can't install Qubes Release 4.0-rc4 in some reason.
> > 
> > 
> > I use the Rufus tool for “DD image” on 8 GB Flash Drive, after that I see 
> > in Boot Menu this 2 kind of select:
> > ---
> > EFI:JetFlashTranscend 8GB 1100HD(Part1,Sig2161DF44)
> > JetFlashTranscend 8GB 1100
> > ---
> > 
> > 
> > 
> > When I choose the 1st one with EFI:... it's showing some black screen:
> > ---
> > Xen 4.8.3 (c/s) EFI loader
> > Using configuration file 'BOOTX64.cfg'
> > vmlinuz: 0x8a01f000-0x8a71adb8
> > initrd.img: 0x88c6f000-0x8a01e64c
> > ---
> > and after that just rebooting.
> > 
> > 
> > But when I choose another JetFlash... it's showing Menu where I can choose 
> > Install methods. I am choosing Install Qubes R4.0-rc4 and see black screen:
> > ---
> > Loading xen.gz... ok
> > Loading vmlinux... ok
> > Loading initrd.img... ok
> > ---
> > and after that flickering cursor on whole black sreen and rebooting.
> > 
> > 
> > How and what I must fix?
> 
> Not all hardware systems (UEFI firmware etc.) can boot up Qubes (or even 
> other Linux distro's), even if you disable the secure boot and other various 
> settings that can cause issues, it might still not be possible. So there is a 
> "risk" that you can't get the UEFI boot to work. Though it may also just be a 
> rogue setting you need to change, but even so, it might still prove 
> impossible in the end.
> 
> Did you try install with LegacyBIOS/Grub? New isn't always better, and 
> UEFI/EFI is by no means bug free, unexploitable or more stable, so this is a 
> scenario where new really isn't "better". For that matter, LegacyBIOS/Grub is 
> pretty much its equal when it comes to security, stability and reliability, 
> if not better.
> 
> Booting with Grub or similar Linux boot manaters is also more versatile, you 
> can easier change kernel/xen versions during boot, if you one day should need 
> to. If you use UEFI/EFI, then it's a bit annoying having to kind of "hack" 
> your own system with a live-boot medium just to change the configuration 
> file. Not that it's very difficult, it's just annoying, and it may also be 
> difficult for the first time a person needs to do it.
> 
> Try LegacyBIOS/Grub boot instead, see if it gives you better results. This 
> also has another benefit being you can also easier enable/disable graphic 
> drivers and such in the Grub menu, which makes it easier to troubleshoot the 
> issue by trial and error'ing.
> 
> btw, does your hardware meet Qubes 4 minimum hardware recommendations? (It's 
> not a question of work-power here, but required features), and are these 
> features enabled in your BIOS/UEFI? Is it new hardware? Old hardware? Have 
> you successfully run any Linux distry on it in the past?

Thank you for your answer.

Yes I tried to install with LegacyBIOS/Grub (in BIOS I chose 'Disabled' in 'EFI 
Optimized Boot':
https://prnt.sc/ii5d61
https://prnt.sc/ii5dqy
https://prnt.sc/ii5e6x

Yes I already have another installed Qubes Release 3.2 which is working only 
with 'Xen 4.6.6 Linux 4.4.14-11.pvops.qubes.x86_64':
https://prnt.sc/ii5iih
https://prnt.sc/ii5ioz
https://prnt.sc/ii5ith

-- 
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 post to this group, send email to qubes-users@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/qubes-users/25577542-7836-4554-ac25-fe6d3dedd49b%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.


Re: [qubes-users] Re: Qubes 3.2: Network doesn't connect automatically with hidden wifi

2018-02-21 Thread Yuraeitha
On Thursday, February 22, 2018 at 3:20:32 AM UTC+1, Max Andersen wrote:
> Sendt fra min iPhone
> 
> > Den 21. feb. 2018 kl. 21.23 skrev Yuraeitha :
> > 
> >> On Wednesday, February 21, 2018 at 8:13:44 PM UTC+1, Max Andersen wrote:
> >> Hi,
> >> 
> >> I've noticed that after disabling SSID broadcast on my wifi, I need to
> >> disable and reenable my network, every time I login.
> >> 
> >> I've tried to describe it in detail here: https://militant.dk/?p=174
> >> 
> >> Maybe anyone has ideas to resolve this?
> >> 
> >> Sincerely
> >> 
> >> Max
> > 
> > Think of it this way. Hackers love challenges. By the act of trying to hide 
> > that way, you're giving a hacker a challenge. He or she, may even get a 
> > kick out of showing you how insecure your network really is by messing with 
> > you, simply because you do something that has no effect, such as hiding the 
> > SSID. 
> > 
> > You're either giving them a challenge to work on, or it might even be 
> > schadenfreude https://en.wikipedia.org/wiki/Schadenfreude
> > 
> > Tbh, you're better off just enabling SSID again.
> 
> So, the solution is actually security by nudging?
> 
> Don’t do it, or we will make qubes network manager crash to nudge you back :)
> 
> I’d bet my network is not that interesting for a wardriving kali hacker, but 
> it still seem like a bug that I would love to get fixed.
> 
> Sincerely
> Max

hehe, well you can probably find a hack to get what you need, for example 
making a script that automatically repairs your connection at boot. I'm not 
seeing the particular details atm, but it seems like it might just work. I'm no 
expert though.

The bug itself is likely not related to Qubes btw. It's very likely that it 
belongs upstream in Fedora, and even in Fedora the Network Manager may come 
from up further upstream. Even if you track down the Network Manager 
developers, the piece of code they're using may come even further upstream, and 
even there, it may yet again come from another upstream. This is usually called 
upstream/downstream movements. Linux is like lego, many pieces comes elsewhere, 
and no one have the resources to do everything. If they tried, they'd drawn in 
work to do. And if they change upstream code, then it becomes really, really 
messy when new updates arrive from upstream, and you need to incorporate the 
code changes you made to all your packages every time a new update arrives. To 
make matters worse, it's not their code, so it can be hard to find your way 
around and find the right places in the code, wasting a lot of time. And then 
there is the aspect that security can be tough to enforce if you spread out too 
far. You have to trust other developers to some extent, otherwise you'd spend 
all your time looking for security flaws and never get anything else done.

The closer to you get to the source upstream, the higher your odds are that a 
developer will track it down and report the issue. Qubes is pretty far away 
from the source, and operates on a more broad level of coding 
(macro-perspective, piecing a lot of different codes and mechanism together). 
You can kind of look at Qubes as an infrastructure, and not an organ like 
operation systems are. Qubes in and on itself is not an operation system, it's 
a network or "mesh" of operation systems. So this issue has to be tracked down.

It's also an issue if developers have to spend time reporting all the bugs to 
each others, they'd spend a huge amount of time on that. A single bug may not 
seem like wasting a lot of time, but it piles up. Say one spends 20 dollars, 
it's pennies, not a lot of money (well at least in some countries). Now imagine 
if you had to pay for 1.000 pieces, then it becomes 20.000 dollars, and it 
suddenly became very expensive. 

That's why developers have to prioritize their time and focus, because if they 
do not, they'd drawn in everything else. Qubes top priority is security. I 
doubt they will be looking into this bug.

But the community can help, by reporting the bug closer to the source, or at 
the actual source. This way the bug can get fixed, and it may go faster too 
(not always though) if the actual developers behind it are reported about it 
directly. If the community does this, it'll save all developers a huge amount 
of time. So this kind of bug, may be a matter of tracking down the actual 
Network Manager developers. 

But if you'd like a fix though, a sort of "hack", then as mentioned earlier, a 
script may work out. But before trying to look into it, I'll ask if this is 
something you need? or do you prefer to wait for a real bug fix? (It can take a 
long time for what may be deemed minor bugs, and also requires someone 
reporting it at the appropriate issue-tracker).

I may not be able to make such a script though, I'm only an average Linux user. 
But I'll try see if I can work something out, however, 
sleep/work/responsibilities up ahead, and things I gotta do, so it might take a 
while before I 

[qubes-users] Re: Qubes OS 4.0RC4 can't get xterm from sys-usb, sys-net, sys-whonix

2018-02-21 Thread wyory
Hi,

This resolved after I restarted. Seems to be part of some
hard-to-pin-down bugs in 4.0rc4. I'll hang tight as things are ironed out.

Thanks for the help.

-wyory

wyory:
> Hi,
> 
> I can't get anything to run using 'qvm-run' on the sys-vms (sys-usb,
> sys-net, sys-whonix). Is this intentional? I'd like to get xterm on
> sys-usb to run some disk diagnostics on an external drive using 'smartctl.'
> 
> Any suggestions?
> 
> Using Qubes OS 4.0RC4.
> 
> Thanks in advance.
> 
> -wyory
> 

-- 
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 post to this group, send email to qubes-users@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/qubes-users/08377d59-1bfe-57c9-0e20-5f8b76c6e1cd%40riseup.net.
For more options, visit https://groups.google.com/d/optout.


AW: [qubes-users] Re: i3 under Qubes 4 RC3

2018-02-21 Thread '[799]' via qubes-users
Hello,

 Original-Nachricht 
An 26. Jan. 2018, 10:18, aaq via qubes-users schrieb:

> My dmenu is broken, for starters. Dmenu only
> shows dom0 applications, so I cannot start
> anything that way.
> When I run qvm-run to start something, I can
> see that my VM is started (with qvm-ls) and I
> can hear my CPU responding (as in it starts
> fanning), but nothing visually happens.
> Nothing is ever started.

Same problem for me, but I haven't found a solution. Using Qubes 4rc4 but i3 is 
not working like it has under Qubes 3.2.

Anyone else using i3 under Q4rc4?

[799]

-- 
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 post to this group, send email to qubes-users@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/qubes-users/spAy2oxk35wRL-Hgx6meItSOdM934bSnC2ohdym9R-wI_d6vCuAgR9y0H0vYgnOUwwJZjyxDHPnE09Oy5IQwBt0F6N2B8O4j6u1vCcyQRJc%3D%40protonmail.com.
For more options, visit https://groups.google.com/d/optout.


Re: [qubes-users] Re: Qubes 3.2: Network doesn't connect automatically with hidden wifi

2018-02-21 Thread 'Max Andersen' via qubes-users


Sendt fra min iPhone

> Den 21. feb. 2018 kl. 21.23 skrev Yuraeitha :
> 
>> On Wednesday, February 21, 2018 at 8:13:44 PM UTC+1, Max Andersen wrote:
>> Hi,
>> 
>> I've noticed that after disabling SSID broadcast on my wifi, I need to
>> disable and reenable my network, every time I login.
>> 
>> I've tried to describe it in detail here: https://militant.dk/?p=174
>> 
>> Maybe anyone has ideas to resolve this?
>> 
>> Sincerely
>> 
>> Max
> 
> Think of it this way. Hackers love challenges. By the act of trying to hide 
> that way, you're giving a hacker a challenge. He or she, may even get a kick 
> out of showing you how insecure your network really is by messing with you, 
> simply because you do something that has no effect, such as hiding the SSID. 
> 
> You're either giving them a challenge to work on, or it might even be 
> schadenfreude https://en.wikipedia.org/wiki/Schadenfreude
> 
> Tbh, you're better off just enabling SSID again.

So, the solution is actually security by nudging?

Don’t do it, or we will make qubes network manager crash to nudge you back :)

I’d bet my network is not that interesting for a wardriving kali hacker, but it 
still seem like a bug that I would love to get fixed.

Sincerely
Max


-- 
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 post to this group, send email to qubes-users@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/qubes-users/CE8AE914-924E-4A56-B1F6-1D7EF649472F%40militant.dk.
For more options, visit https://groups.google.com/d/optout.


Re: [qubes-users] HTTP proxy & firewall woes

2018-02-21 Thread Unman
On Wed, Feb 21, 2018 at 06:42:44PM -0500, Demi M. Obenour wrote:
> 
> 
> On 02/21/2018 04:59 PM, Demi M. Obenour wrote:
> >
> > On 02/21/2018 08:36 AM, awokd wrote:
> >> On Wed, February 21, 2018 12:55 pm, Demi Obenour wrote:
> >>> Weird.  Proxy logs indicate that the proxy never receives a CONNECT
> >>> request from Firefox.
> >>>
> >>> On Feb 21, 2018 4:08 AM, "awokd"  wrote:
> >>>
> >>>
>  On Tue, February 20, 2018 5:09 pm, Demi M. Obenour wrote:
> 
> > I use GMail and Thunderbird for email, and Firefox as my browser.  I
> > do email and GitHub from a different domain that is more trusted than
> > others (it’s blue).
> >
> >
> >
> > I would love to restrict its networking abilities by using firewall
> > rules or a filtering proxy.  Sadly, I have not been able to do that
>  without
> > breaking at least GMail.  For firewall rules, the culprit seems to be
> >  Google’s use of DNS load balancing, but I am not sure what is
> > breaking for the filtering proxy.  OCSP stapling?
> >
> > I would much prefer to be able to restrict network access, but I
> > cannot break what needs to work.  Does anyone have suggestions?
>  Probably OCSP stapling like you said. Some filtering proxies can be
>  configured to pass through SSL/TLS sessions unmolested, but then they
>  can't filter them by content. You might also try POP3/SMTP vs. IMAP
>  although Gmail probably uses the same types of certs for both.
> >> Assuming you're on R3.2, have you seen
> >> https://www.qubes-os.org/doc/config/http-filtering-proxy ?
> >> https://www.qubes-os.org/doc/firewall might also be useful if you're
> >> having firewall issues.
> >>
> > I did, and finally figured out the problem:
> >
> > Thunderbird does not support SMTP/IMAP/POP3 over an HTTP proxy, only
> > over a SOCKS proxy.  But the latter is not useful in this case, because
> > a SOCKS5 proxy receives an IP address, not a domain name, and so cannot
> > filter by domain name.  Furthermore, Google uses many, many IP
> > addresses, and rotates them frequently, so one cannot usefully filter by
> > IP address.
> >
> > I am going to be reporting this as a Thunderbird bug — the fix is to use
> > a CONNECT request for SMTP/IMAP/POP3 just as is done for TLS.  In the
> > meantime, I have had no choice but to enable all networking for that
> > domain.  I still gain some security benefit, because Firefox and
> > Thunderbird honor the HTTP proxy settings, and so I cannot accidentally
> > browse to a dangerous site by mistake.
> >
> > I wonder if Evolution would be a better choice than Thunderbird.  It
> > might not have this bug.  Does it have a worse history when it comes to
> > security?
> >
> > Demi
> I just had a further thought: could I work around this?  My thought was
> to use /etc/hosts to force Thunderbird to use a specific IP, then proxy
> that IP using a trivial C program using libcurl.
> 
> Demi
> 

You could try whitelisting IMAP to google net ranges - get the SPF
records using dig _netblocks.google.com txt
I've tried the hosts entries, but it's pretty difficult to do this
effectively given the somewhat opaque way that google will reroute
traffic. You may as well sell your soul and use the blocks -
74.125.0.0/16 covers a good deal of gmail imap if i recall.
At least you'll have some restrictions on outgoing traffic.

-- 
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 post to this group, send email to qubes-users@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/qubes-users/20180222021719.m4h2nzkojyfzqirt%40thirdeyesecurity.org.
For more options, visit https://groups.google.com/d/optout.


[qubes-users] HVM resolution not working by changing xorg.conf

2018-02-21 Thread snowboard789
I installed an HVM of Linux Mint 18 on a laptop. I followed everything that is 
in the HVM tips and changed the driver to vesa, the horiz sync to 30-60 the 
vert refresh to 40-80 (and tried without it). I tried hardcoding resolutions 
and not hardcoding them. 

I get a sync problem as long as I log in (the login screen is huge but ok). 
Then it's all totally fuzzy.

What else can I try? Thanks

-- 
You received this message because you are subscribed to the Google Groups 
"qubes-users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to qubes-users+unsubscr...@googlegroups.com.
To post to this group, send email to qubes-users@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/qubes-users/275cf3ed-c255-4693-b4e7-02d9f298ae4b%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.


Re: [qubes-users] Re: Trying to install Ubuntu as HVM can't restart

2018-02-21 Thread Unman
On Wed, Feb 21, 2018 at 03:33:22PM -0800, snowboard...@gmail.com wrote:
> On Monday, February 19, 2018 at 5:18:33 PM UTC+1, Unman wrote:
> > On Mon, Feb 19, 2018 at 05:44:44AM -0800, snowboard...@gmail.com wrote:
> > > On Monday, February 19, 2018 at 2:36:08 PM UTC+1, Yuraeitha wrote:
> > > > On Monday, February 19, 2018 at 1:20:24 PM UTC+1, snowbo...@gmail.com 
> > > > wrote:
> > > > > I feel like a total idiot here but here is what I am doing:
> > > > > 
> > > > > 1) I make an HVM (tried both normal and template) and then assign 
> > > > > more disk space to it. 
> > > > > 2) I download the ubuntu iso file for desktop.
> > > > > 3) I run qvm-start ubuntu --cdrom=vmpath:/home/user/downloads/xxx.iso
> > > > > 4) I run the installation that surprisingly finishes ultra fast. 
> > > > > There are two disks one is xvda and xvdb. The first has the space 
> > > > > that VM has for "personal usage" and the second for "system". I tried 
> > > > > installing on both with same result.
> > > > > 5) As the installation finishes when I shutdown the machine it 
> > > > > doesn't shutdown. A black window keeps on. Then I kill it with 
> > > > > Qubes-manager.
> > > > > 6) after that it doesn't start. It says booting from hard drive but 
> > > > > nothing happens.
> > > > > 
> > > > > I tried many times. What am I doing wrong?
> > > > > 
> > > > > thanks in advance
> > > > 
> > > > Don't label yourself as an idiot. Although I'm not an expert, but your 
> > > > logical approach seems pretty good to me, you try to find the reason 
> > > > and logic behind it. No matter what, trying to solve it is a good 
> > > > logical quality.
> > > > 
> > > > As for why it doesn't work, it seems like a driver issue for graphics? 
> > > > You could try change the AppVM's grub menu, and put a different graphic 
> > > > driver, xdriver=vesa, nomodeset, or something along those lines. Vast 
> > > > topics can be found on this issue, now that you can suspect graphiic 
> > > > issues, you can more easily find these topics to try troubleshoot it if 
> > > > neither commands above work.
> > > > 
> > > > You can also try change the used kernel to '' blank, since Ubuntu 
> > > > custom install without Qubes code, probably has no means to use its own 
> > > > kernel pulled from dom0 kernels, and the Ubuntu kernel may try to boot 
> > > > up while the VM kernel's located in dom0. As such, there may be a 
> > > > conflict here? I'm not sure if this is what is happening, but you can 
> > > > try put the qvm-prefs for the kernel in blank, install again and see 
> > > > what happens, it should allow Ubuntu to use its own kernel, I believe.
> > > > 
> > > > btw, for what purposes are you getting Ubuntu? By any chance is it 
> > > > codecs? are the other reasons? It may be more efficient to fix up 
> > > > Fedora or Debian, instead of getting Ubuntu up and running. It's just 
> > > > that there are so many Ubuntu questions lately, I'm a bit lost as to 
> > > > why people would want Ubuntu if they installed Qubes OS. Qubes OS is a 
> > > > bit of a leap to jump from Ubuntu, Debian or Fedora isn't that bad for 
> > > > next steps after Ubuntu, but Qubes OS may be a bit of a leap in its 
> > > > current state. 
> > > > 
> > > > The only real nice thing is the ease to install nvidia drivers, but 
> > > > that is hardly something you will end up needing in Qubes anyway. Can I 
> > > > ask what you need Ubuntu for? and perhaps if you desire to give it a 
> > > > shot for an alternative, and try Fedora and Debian to get the tasks 
> > > > done you usually do on Ubuntu? If you still feel like going for Ubuntu, 
> > > > then that's fine, I won't get in the way for that. 
> > > > 
> > > > As such, if keeping Ubuntu, fixing graphic drivers may be a good place 
> > > > to start here?
> > > 
> > > Hi thanks I will try that. I am using Ubuntu because Debian 8 is such a 
> > > pain when installing new software. You need to enable testing and 
> > > unstable repos and then you end up with a mixed system then things break 
> > > down etc. Ubuntu 16 is for sure compatible with most software oob for the 
> > > next 2 years. 
> > > 
> > 
> > Can you try again, just installing to the first disk?(xvda)
> > Also, make sure that you have enough memory allocated:
> > qvm-prefs  -s memory 8192
> > qvm-prefs  -s maxmem 8192
> > 
> > You're doing the right thing, and as you can boot from the iso all
> > should be fine. There are issues with Ubuntu resolution when running as
> > VM - you can see reference to this in the list in the past. Changing
> > graphics drivers wont help with that issue.
> 
> want to report that I found the problem. it was encrypted home folder. 
> unchecked works ok. not sure if i should post it on github. 
> 

I doubt this is the cause, because I have HVMs with encrypted home
folders and they start fine.(For me this works installing to xvda.)
I dont think a github issue would be appropriate.
Anyway, glad you are up and running.

-- 
You received this message 

Re: [qubes-users] DispVM change Template

2018-02-21 Thread Unman
On Wed, Feb 21, 2018 at 09:13:16PM -, klausdiet...@mail2tor.com wrote:
> Hello,
> 
> Is it possible to change the DispVM Template? I want the changes i made in
> Firefox one time are always in the new DispVM愀 i create.
> 
> For example: I install "NoScript" in the DispVM Template in Firefox,
> so if i open a new fresh DispVM with Firefox, i want to have "NoScript"
> everytime i open a new Firefox in DispVM.
> 
> 
> Best regards
> 
You havent said which version of Qubes you are using.
It's simple to do what you want, and it's covered in detail in the docs
- look at this page:
https://www.qubes-os.org/doc/dispvm-customization/

-- 
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 post to this group, send email to qubes-users@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/qubes-users/20180222014243.ojemj5josk7wb2jg%40thirdeyesecurity.org.
For more options, visit https://groups.google.com/d/optout.


[qubes-users] Re: Building Centos template conflict error?

2018-02-21 Thread Tim W
AWESOME!!!

Thanks for taking the time post the update.  I will build as soon as I get home 
and report back.

Should it build ok as part of the qubes os iso as well?

-- 
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 post to this group, send email to qubes-users@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/qubes-users/c96efe32-26a0-4f91-aeb1-d3dfd8619ef7%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.


[qubes-users] Re: Can't install Qubes, Rebooting after loading initrd.img

2018-02-21 Thread Tim W
Need more info for.people to help you.  Your lqptop hardware make model 
processor is it one off the qubes list that shows its supported.  What is the 
graphic card?  Mnay blackscrn flicker issues are video card related i.e. nvidia 
amd.

-- 
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 post to this group, send email to qubes-users@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/qubes-users/75ad4c58-6942-43da-90f0-12f1520f46d2%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.


Re: [qubes-users] HTTP proxy & firewall woes

2018-02-21 Thread Tim W
Evolution should work.  It did have a bug back in 2012 but that was it from 
what I recall.

Evolution also does not au5omatucally folliw gnomes setting and has its own.  

Open Evolution > Edit> Preferences > Network Prefences > you should see default 
proxy setting page with a link to open advanced setting.  But in the basic page 
you have entries for http https and socks proxy config.

Its been a long time but it should be there or close to it.   I have found I 
enjoy Evolution over t-bird.  Maybe its just the change but it seems smoother 
and not so heavy laiden. Firefox has also gotten chubby and away from its sleek 
roots as well.   For max email effiency I find a terminal email app still has 
its place not to mention simplifies things. Mutt, Sup, Alpine.  Sup is pretfy 
cool with its power and use of tags organization.

Anyways hope that Evolution info is helpful.

-- 
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 post to this group, send email to qubes-users@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/qubes-users/e885a5d3-37e3-4945-8f32-23bb06c20b59%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.


Re: [qubes-users] HTTP proxy & firewall woes

2018-02-21 Thread Demi M. Obenour


On 02/21/2018 04:59 PM, Demi M. Obenour wrote:
>
> On 02/21/2018 08:36 AM, awokd wrote:
>> On Wed, February 21, 2018 12:55 pm, Demi Obenour wrote:
>>> Weird.  Proxy logs indicate that the proxy never receives a CONNECT
>>> request from Firefox.
>>>
>>> On Feb 21, 2018 4:08 AM, "awokd"  wrote:
>>>
>>>
 On Tue, February 20, 2018 5:09 pm, Demi M. Obenour wrote:

> I use GMail and Thunderbird for email, and Firefox as my browser.  I
> do email and GitHub from a different domain that is more trusted than
> others (it’s blue).
>
>
>
> I would love to restrict its networking abilities by using firewall
> rules or a filtering proxy.  Sadly, I have not been able to do that
 without
> breaking at least GMail.  For firewall rules, the culprit seems to be
>  Google’s use of DNS load balancing, but I am not sure what is
> breaking for the filtering proxy.  OCSP stapling?
>
> I would much prefer to be able to restrict network access, but I
> cannot break what needs to work.  Does anyone have suggestions?
 Probably OCSP stapling like you said. Some filtering proxies can be
 configured to pass through SSL/TLS sessions unmolested, but then they
 can't filter them by content. You might also try POP3/SMTP vs. IMAP
 although Gmail probably uses the same types of certs for both.
>> Assuming you're on R3.2, have you seen
>> https://www.qubes-os.org/doc/config/http-filtering-proxy ?
>> https://www.qubes-os.org/doc/firewall might also be useful if you're
>> having firewall issues.
>>
> I did, and finally figured out the problem:
>
> Thunderbird does not support SMTP/IMAP/POP3 over an HTTP proxy, only
> over a SOCKS proxy.  But the latter is not useful in this case, because
> a SOCKS5 proxy receives an IP address, not a domain name, and so cannot
> filter by domain name.  Furthermore, Google uses many, many IP
> addresses, and rotates them frequently, so one cannot usefully filter by
> IP address.
>
> I am going to be reporting this as a Thunderbird bug — the fix is to use
> a CONNECT request for SMTP/IMAP/POP3 just as is done for TLS.  In the
> meantime, I have had no choice but to enable all networking for that
> domain.  I still gain some security benefit, because Firefox and
> Thunderbird honor the HTTP proxy settings, and so I cannot accidentally
> browse to a dangerous site by mistake.
>
> I wonder if Evolution would be a better choice than Thunderbird.  It
> might not have this bug.  Does it have a worse history when it comes to
> security?
>
> Demi
I just had a further thought: could I work around this?  My thought was
to use /etc/hosts to force Thunderbird to use a specific IP, then proxy
that IP using a trivial C program using libcurl.

Demi

-- 
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 post to this group, send email to qubes-users@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/qubes-users/e79e2835-cf18-019f-0d51-439a7d4025d1%40gmail.com.
For more options, visit https://groups.google.com/d/optout.


0xFF9C22C1.asc
Description: application/pgp-keys


signature.asc
Description: OpenPGP digital signature


Re: [qubes-users] Re: Trying to install Ubuntu as HVM can't restart

2018-02-21 Thread snowboard789
On Monday, February 19, 2018 at 5:18:33 PM UTC+1, Unman wrote:
> On Mon, Feb 19, 2018 at 05:44:44AM -0800, snowboard...@gmail.com wrote:
> > On Monday, February 19, 2018 at 2:36:08 PM UTC+1, Yuraeitha wrote:
> > > On Monday, February 19, 2018 at 1:20:24 PM UTC+1, snowbo...@gmail.com 
> > > wrote:
> > > > I feel like a total idiot here but here is what I am doing:
> > > > 
> > > > 1) I make an HVM (tried both normal and template) and then assign more 
> > > > disk space to it. 
> > > > 2) I download the ubuntu iso file for desktop.
> > > > 3) I run qvm-start ubuntu --cdrom=vmpath:/home/user/downloads/xxx.iso
> > > > 4) I run the installation that surprisingly finishes ultra fast. There 
> > > > are two disks one is xvda and xvdb. The first has the space that VM has 
> > > > for "personal usage" and the second for "system". I tried installing on 
> > > > both with same result.
> > > > 5) As the installation finishes when I shutdown the machine it doesn't 
> > > > shutdown. A black window keeps on. Then I kill it with Qubes-manager.
> > > > 6) after that it doesn't start. It says booting from hard drive but 
> > > > nothing happens.
> > > > 
> > > > I tried many times. What am I doing wrong?
> > > > 
> > > > thanks in advance
> > > 
> > > Don't label yourself as an idiot. Although I'm not an expert, but your 
> > > logical approach seems pretty good to me, you try to find the reason and 
> > > logic behind it. No matter what, trying to solve it is a good logical 
> > > quality.
> > > 
> > > As for why it doesn't work, it seems like a driver issue for graphics? 
> > > You could try change the AppVM's grub menu, and put a different graphic 
> > > driver, xdriver=vesa, nomodeset, or something along those lines. Vast 
> > > topics can be found on this issue, now that you can suspect graphiic 
> > > issues, you can more easily find these topics to try troubleshoot it if 
> > > neither commands above work.
> > > 
> > > You can also try change the used kernel to '' blank, since Ubuntu custom 
> > > install without Qubes code, probably has no means to use its own kernel 
> > > pulled from dom0 kernels, and the Ubuntu kernel may try to boot up while 
> > > the VM kernel's located in dom0. As such, there may be a conflict here? 
> > > I'm not sure if this is what is happening, but you can try put the 
> > > qvm-prefs for the kernel in blank, install again and see what happens, it 
> > > should allow Ubuntu to use its own kernel, I believe.
> > > 
> > > btw, for what purposes are you getting Ubuntu? By any chance is it 
> > > codecs? are the other reasons? It may be more efficient to fix up Fedora 
> > > or Debian, instead of getting Ubuntu up and running. It's just that there 
> > > are so many Ubuntu questions lately, I'm a bit lost as to why people 
> > > would want Ubuntu if they installed Qubes OS. Qubes OS is a bit of a leap 
> > > to jump from Ubuntu, Debian or Fedora isn't that bad for next steps after 
> > > Ubuntu, but Qubes OS may be a bit of a leap in its current state. 
> > > 
> > > The only real nice thing is the ease to install nvidia drivers, but that 
> > > is hardly something you will end up needing in Qubes anyway. Can I ask 
> > > what you need Ubuntu for? and perhaps if you desire to give it a shot for 
> > > an alternative, and try Fedora and Debian to get the tasks done you 
> > > usually do on Ubuntu? If you still feel like going for Ubuntu, then 
> > > that's fine, I won't get in the way for that. 
> > > 
> > > As such, if keeping Ubuntu, fixing graphic drivers may be a good place to 
> > > start here?
> > 
> > Hi thanks I will try that. I am using Ubuntu because Debian 8 is such a 
> > pain when installing new software. You need to enable testing and unstable 
> > repos and then you end up with a mixed system then things break down etc. 
> > Ubuntu 16 is for sure compatible with most software oob for the next 2 
> > years. 
> > 
> 
> Can you try again, just installing to the first disk?(xvda)
> Also, make sure that you have enough memory allocated:
> qvm-prefs  -s memory 8192
> qvm-prefs  -s maxmem 8192
> 
> You're doing the right thing, and as you can boot from the iso all
> should be fine. There are issues with Ubuntu resolution when running as
> VM - you can see reference to this in the list in the past. Changing
> graphics drivers wont help with that issue.

want to report that I found the problem. it was encrypted home folder. 
unchecked works ok. not sure if i should post it on github. 

-- 
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 post to this group, send email to qubes-users@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/qubes-users/5755b7c9-7423-428c-b0eb-ba8e388d6b8a%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.


[qubes-users] Re: [qubes-devel] Re: [qubes-announce] QSB #38: Qrexec policy bypass and possible information leak

2018-02-21 Thread Tim W
That is uncalled for and just common.  Toms comments were constructive and 
topic specific.  Sure, showing some frustration as we all have from time to 
time,  but your comment was just common thug personal attack and has no place 
here.  In fact I do not see where you have offered a single thing of on topic 
value, only a vulgar personal attck.

FYI. Many of us are professionals in the field and I for one do not expect to 
be speak or be spoken to by anyone in such a mannner even if it is the net 
where people can hide behind screen names and distance.  Maybe take your own 
advice if that is how you handle a small bit of critism, debate, and 
disagreement.  


Respectfully,

Tim  

-- 
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 post to this group, send email to qubes-users@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/qubes-users/c94b7335-2337-4790-9976-c959da5f45cf%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.


Re: [qubes-users] Re: DispVM Firefox through TOR

2018-02-21 Thread 'awokd' via qubes-users
On Wed, February 21, 2018 11:20 pm, pixel fairy wrote:
> On Wednesday, February 21, 2018 at 3:18:34 PM UTC-8, pixel fairy wrote:
>
>> On Wednesday, February 21, 2018 at 2:15:56 PM UTC-8,
>> klausd...@mail2tor.com wrote:
>>
>>> Is it possible to root a Firefox instance of a DispVM trough Tor?
>>>
>>>
>>> Were can i change the netsys to sys-whonix for Disp´VM?
>>>
>>>
>>> Thank you very much :)
>>>
>>
>> just set the network vm in the vm settings basic tab. in qubes 3.2,
>> this is in the qubes manager. in 4.0 its in the Q menu on the top left.
>>
>
> correction, when using disposable VMs in qubes-4, you have to use the "Q"
> menu on the top RIGHT, not left.

If you're going to do that though, I suggest creating a disposable VM
based on the whonix-ws template and using Tor Browser instead of Firefox.
The procedure is different between Qubes versions, and a bit hard to do on
R3.2.


-- 
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 post to this group, send email to qubes-users@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/qubes-users/45461689acce08f31a1492fe6f081a37.squirrel%40tt3j2x4k5ycaa5zt.onion.
For more options, visit https://groups.google.com/d/optout.


[qubes-users] Re: DispVM Firefox through TOR

2018-02-21 Thread pixel fairy
On Wednesday, February 21, 2018 at 3:18:34 PM UTC-8, pixel fairy wrote:
> On Wednesday, February 21, 2018 at 2:15:56 PM UTC-8, klausd...@mail2tor.com 
> wrote:
> > Is it possible to root a Firefox instance of a DispVM trough Tor?
> > 
> > Were can i change the netsys to sys-whonix for Disp´VM?
> > 
> > Thank you very much :)
> 
> just set the network vm in the vm settings basic tab. in qubes 3.2, this is 
> in the qubes manager. in 4.0 its in the Q menu on the top left.

correction, when using disposable VMs in qubes-4, you have to use the "Q" menu 
on the top RIGHT, not left.

-- 
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 post to this group, send email to qubes-users@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/qubes-users/16c20591-23e1-4a53-b313-a95d1adfa792%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.


[qubes-users] Re: DispVM Firefox through TOR

2018-02-21 Thread pixel fairy
On Wednesday, February 21, 2018 at 2:15:56 PM UTC-8, klausd...@mail2tor.com 
wrote:
> Is it possible to root a Firefox instance of a DispVM trough Tor?
> 
> Were can i change the netsys to sys-whonix for Disp´VM?
> 
> Thank you very much :)

just set the network vm in the vm settings basic tab. in qubes 3.2, this is in 
the qubes manager. in 4.0 its in the Q menu on the top left.

-- 
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 post to this group, send email to qubes-users@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/qubes-users/5a6756b0-6572-49dd-851f-aa689160ce7d%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.


[qubes-users] DispVM Firefox through TOR

2018-02-21 Thread KlausDieter2
Is it possible to root a Firefox instance of a DispVM trough Tor?

Were can i change the netsys to sys-whonix for Disp´VM?

Thank you very much :)

-- 
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 post to this group, send email to qubes-users@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/qubes-users/065a481a40775fe6f12cfe50d43a3a3d.squirrel%40_.
For more options, visit https://groups.google.com/d/optout.


Re: [qubes-users] QSB #38: Qrexec policy bypass and possible information leak

2018-02-21 Thread donoban
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

On 02/21/2018 10:58 PM, donoban wrote:
> On 02/20/2018 03:18 PM, donoban wrote:
>> Hi,
> 
>> After upgrading Qubes 3.2 with the patches all seems fine.
> 
> 
> I noticed updates from qubes-manager are not working in Qubes 3.2.
> Not sure if it's related with this patch though...
> 
> I'm pretty sure this line is being called:
> 
> vm.run_service("qubes.InstallUpdatesGUI", gui=True, user="root",
> wait=False)
> 
> But nothing happens :\
> 

Looking at systemd logs I noticed it fails because DISPLAY is not set.
-BEGIN PGP SIGNATURE-

iQIzBAEBCAAdFiEEznLCgPSfWTT+LPrmFBMQ2OPtCKUFAlqN7doACgkQFBMQ2OPt
CKVUtxAAjHsP2zj9X39En6P6HmuA8tqrEL48+A7bNb50npFQoJpMpdIsS29WdwkK
/5+0Wq3PHE3UXwUMuxomXr3gAQsqOVrkUeFE3wbS9fiZA5OzMJ7V1HI1zF5+lRmb
Jfo+kTCu8w3hbcGS6vFK2WbaFRtPzGatSsYHNSs++oAa0A0usrTXuQEVJ4roxNm2
qE28FG8ZnvDF2e5mpXwqfsvCYSUPwTe61cgVYTnb0+0cqqi9UP6z+wvR3yYHodfz
3pY/kpTk34/7Ul6WSX4ENFcb5q4e1U/cmxU5ZXRLQxycfErs+YLdZzL5Ql7flPac
x0e/1rWEnOITd0CSsT7v1u0FJRciSZDt/QYb96CruXNlhAltyl3JF2P/ea+EOLqE
WPZjB/wQCw+t4DbCRY+DzbJ/mxuSBUAnCFLyOsrqnbDVefv8esmmBfM+Y8+VGWIS
m3AslW1f5wkzC48LqCmA9gYEqeT92Ch3gej993M0NGfLGreBN7X6gxvCbaaDvexh
ZratzSgciH4WFdqnoBa0GQX7CWMVDlAEyp0gxjhhp05wzj9gtrMSDEKAnRI+EoRz
rAm8dAUd0DN0JBqKeK+zLNCEd1aAjsPxJkB1XNc/S79ha0ByMZd6Lf46IKSBWLl9
Uqya4sKfUfM4QCcjuLZktU5qf6UqJCtNSvvEpLlzxxmnJ5pjxg0=
=G6dD
-END PGP SIGNATURE-

-- 
You received this message because you are subscribed to the Google Groups 
"qubes-users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to qubes-users+unsubscr...@googlegroups.com.
To post to this group, send email to qubes-users@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/qubes-users/023f8ce7-a249-d91c-f7df-933cd099b9eb%40riseup.net.
For more options, visit https://groups.google.com/d/optout.


Re: [qubes-users] QSB #38: Qrexec policy bypass and possible information leak

2018-02-21 Thread donoban
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

On 02/20/2018 03:18 PM, donoban wrote:
> Hi,
> 
> After upgrading Qubes 3.2 with the patches all seems fine.


I noticed updates from qubes-manager are not working in Qubes 3.2. Not
sure if it's related with this patch though...

I'm pretty sure this line is being called:

  vm.run_service("qubes.InstallUpdatesGUI", gui=True,
   user="root", wait=False)

But nothing happens :\
-BEGIN PGP SIGNATURE-

iQIzBAEBCAAdFiEEznLCgPSfWTT+LPrmFBMQ2OPtCKUFAlqN65gACgkQFBMQ2OPt
CKWGRw/+LhzHUgYdQW89f1bTvS+UpPhxqhE5jKKQv0pZpLAsZU5u9kZnf4+czxq1
dN0ZW5cGg0NwAg1ra3rvpclKKat+IkcmhN5yFJ5IVlSzmjTHLJ6T6LjoPnmyc0iD
XRaWNaGu+3Gg8jQmiCJ9i0ZgbdgdHegbLRpKu5R5jnO0ux1wAVTrpo3OEJfijUx+
26sGbSGVh+K2XD5nXk3xHd44F1K3/iJYBTRLcUYzoSH5kN94gs/AgUFqd1XgrIRs
o5pi/kC5Qkp0bBFptpV2yCQY+b2KCpGHsqoIa43WLR/qpxjHr39FXqAgkzlVq8DC
LIoWRfljv4B7GmvoOSfBCdigaFKInPKX3XJA+dRzVW8aMZQZ/ZjYz2YLnDzw+qnR
zA/Qv1OAJ32GtGoUEbhux2STOekbNgnyx5nyBRMUjZMSWDoTlyJrH2ZJg7o/BBok
juIBqtB91niAWBUZwbR7NMvLI5GAAkVL2yWx0lSVaYrjPBXhafME3/SXY4q7fNwu
JalDGLt0Qii3XpPrH1mCZ5Jild7gn0Eg54BTwvtM/xxGGPH9j876m32w7PuTeO70
OHL7yM0ZEOF8FDOe0/PHIeXEGhPtX2oWIzsAIdEOqiDCGjVzpvMtXPAFLlHO1drK
wwp9o/8TnhNROSJz2QJDJkvaeYF5D/qm2zLAn/hfMRwpWWmJbz8=
=PGjU
-END PGP SIGNATURE-

-- 
You received this message because you are subscribed to the Google Groups 
"qubes-users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to qubes-users+unsubscr...@googlegroups.com.
To post to this group, send email to qubes-users@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/qubes-users/64f5978b-2a7a-fc8e-5418-5235ceeff5d6%40riseup.net.
For more options, visit https://groups.google.com/d/optout.


Re: [qubes-users] HTTP proxy & firewall woes

2018-02-21 Thread Demi M. Obenour


On 02/21/2018 08:36 AM, awokd wrote:
> On Wed, February 21, 2018 12:55 pm, Demi Obenour wrote:
>> Weird.  Proxy logs indicate that the proxy never receives a CONNECT
>> request from Firefox.
>>
>> On Feb 21, 2018 4:08 AM, "awokd"  wrote:
>>
>>
>>> On Tue, February 20, 2018 5:09 pm, Demi M. Obenour wrote:
>>>
 I use GMail and Thunderbird for email, and Firefox as my browser.  I
 do email and GitHub from a different domain that is more trusted than
 others (it’s blue).



 I would love to restrict its networking abilities by using firewall
 rules or a filtering proxy.  Sadly, I have not been able to do that
>>> without
 breaking at least GMail.  For firewall rules, the culprit seems to be
  Google’s use of DNS load balancing, but I am not sure what is
 breaking for the filtering proxy.  OCSP stapling?

 I would much prefer to be able to restrict network access, but I
 cannot break what needs to work.  Does anyone have suggestions?
>>> Probably OCSP stapling like you said. Some filtering proxies can be
>>> configured to pass through SSL/TLS sessions unmolested, but then they
>>> can't filter them by content. You might also try POP3/SMTP vs. IMAP
>>> although Gmail probably uses the same types of certs for both.
> Assuming you're on R3.2, have you seen
> https://www.qubes-os.org/doc/config/http-filtering-proxy ?
> https://www.qubes-os.org/doc/firewall might also be useful if you're
> having firewall issues.
>
I did, and finally figured out the problem:

Thunderbird does not support SMTP/IMAP/POP3 over an HTTP proxy, only
over a SOCKS proxy.  But the latter is not useful in this case, because
a SOCKS5 proxy receives an IP address, not a domain name, and so cannot
filter by domain name.  Furthermore, Google uses many, many IP
addresses, and rotates them frequently, so one cannot usefully filter by
IP address.

I am going to be reporting this as a Thunderbird bug — the fix is to use
a CONNECT request for SMTP/IMAP/POP3 just as is done for TLS.  In the
meantime, I have had no choice but to enable all networking for that
domain.  I still gain some security benefit, because Firefox and
Thunderbird honor the HTTP proxy settings, and so I cannot accidentally
browse to a dangerous site by mistake.

I wonder if Evolution would be a better choice than Thunderbird.  It
might not have this bug.  Does it have a worse history when it comes to
security?

Demi

-- 
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 post to this group, send email to qubes-users@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/qubes-users/08a309c5-4f90-e7d4-dba1-f0211a8a0605%40gmail.com.
For more options, visit https://groups.google.com/d/optout.


0xFF9C22C1.asc
Description: application/pgp-keys


signature.asc
Description: OpenPGP digital signature


[qubes-users] DispVM change Template

2018-02-21 Thread KlausDieter2
Hello,

Is it possible to change the DispVM Template? I want the changes i made in
Firefox one time are always in the new DispVM愀 i create.

For example: I install "NoScript" in the DispVM Template in Firefox,
so if i open a new fresh DispVM with Firefox, i want to have "NoScript"
everytime i open a new Firefox in DispVM.


Best regards


-- 
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 post to this group, send email to qubes-users@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/qubes-users/e233af30be5a86a76eaa93a08bd950e3.squirrel%40_.
For more options, visit https://groups.google.com/d/optout.


[qubes-users] Re: Qubes 3.2: Network doesn't connect automatically with hidden wifi

2018-02-21 Thread Yuraeitha
On Wednesday, February 21, 2018 at 8:13:44 PM UTC+1, Max Andersen wrote:
> Hi,
> 
> I've noticed that after disabling SSID broadcast on my wifi, I need to
> disable and reenable my network, every time I login.
> 
> I've tried to describe it in detail here: https://militant.dk/?p=174
> 
> Maybe anyone has ideas to resolve this?
> 
> Sincerely
> 
> Max

How come you try to hide the SSID? It'll only give you more attention. Out of 
the many identical wi-fi networks out there in the wilds, if a hacker comes 
across a wi-fi that's behaving different, and towards that, trying to "hide", 
it might act as a bait. 

Hackers don't look for SSID's anyway, they look for the actual "signals", and 
no matter how you try to slice it, any working network will require a signal, 
otherwise there will be no network. So it's impossible to hide your wi-fi, and 
it's all the more true when trying to hide it against hackers who will see it 
anyway.

Basically the result is that you'll hide your network from people that poses no 
threat to your digital life anyway. But maybe that's the goal, to try hide the 
network from people with no hacking background for other reasons?

If you're trying to hide it for security reasons, then it's better you make it 
visible and try to "blend in" in the masses. Even if there is no other wi-fi 
nearby, try make it look as normal and "boring" as possible.

-- 
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 post to this group, send email to qubes-users@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/qubes-users/c63af635-250c-43ff-b08c-408b33952f0c%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.


[qubes-users] Re: Can't install Qubes, Rebooting after loading initrd.img

2018-02-21 Thread Yuraeitha
On Wednesday, February 21, 2018 at 9:43:17 AM UTC+1, Daniil .Travnikov wrote:
> I can't install Qubes Release 4.0-rc4 in some reason.
> 
> 
> I use the Rufus tool for “DD image” on 8 GB Flash Drive, after that I see in 
> Boot Menu this 2 kind of select:
> ---
> EFI:JetFlashTranscend 8GB 1100HD(Part1,Sig2161DF44)
> JetFlashTranscend 8GB 1100
> ---
> 
> 
> 
> When I choose the 1st one with EFI:... it's showing some black screen:
> ---
> Xen 4.8.3 (c/s) EFI loader
> Using configuration file 'BOOTX64.cfg'
> vmlinuz: 0x8a01f000-0x8a71adb8
> initrd.img: 0x88c6f000-0x8a01e64c
> ---
> and after that just rebooting.
> 
> 
> But when I choose another JetFlash... it's showing Menu where I can choose 
> Install methods. I am choosing Install Qubes R4.0-rc4 and see black screen:
> ---
> Loading xen.gz... ok
> Loading vmlinux... ok
> Loading initrd.img... ok
> ---
> and after that flickering cursor on whole black sreen and rebooting.
> 
> 
> How and what I must fix?

Not all hardware systems (UEFI firmware etc.) can boot up Qubes (or even other 
Linux distro's), even if you disable the secure boot and other various settings 
that can cause issues, it might still not be possible. So there is a "risk" 
that you can't get the UEFI boot to work. Though it may also just be a rogue 
setting you need to change, but even so, it might still prove impossible in the 
end.

Did you try install with LegacyBIOS/Grub? New isn't always better, and UEFI/EFI 
is by no means bug free, unexploitable or more stable, so this is a scenario 
where new really isn't "better". For that matter, LegacyBIOS/Grub is pretty 
much its equal when it comes to security, stability and reliability, if not 
better.

Booting with Grub or similar Linux boot manaters is also more versatile, you 
can easier change kernel/xen versions during boot, if you one day should need 
to. If you use UEFI/EFI, then it's a bit annoying having to kind of "hack" your 
own system with a live-boot medium just to change the configuration file. Not 
that it's very difficult, it's just annoying, and it may also be difficult for 
the first time a person needs to do it.

Try LegacyBIOS/Grub boot instead, see if it gives you better results. This also 
has another benefit being you can also easier enable/disable graphic drivers 
and such in the Grub menu, which makes it easier to troubleshoot the issue by 
trial and error'ing.

btw, does your hardware meet Qubes 4 minimum hardware recommendations? (It's 
not a question of work-power here, but required features), and are these 
features enabled in your BIOS/UEFI? Is it new hardware? Old hardware? Have you 
successfully run any Linux distry on it in the past?

-- 
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 post to this group, send email to qubes-users@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/qubes-users/16c95747-5fb0-4c1f-bebe-89a8a74c930a%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.


[qubes-users] Re: Can't install Qubes, Rebooting after loading initrd.img

2018-02-21 Thread Daniil .Travnikov
Tried to install from DVD today, but nothing was changed. Can anybody help 
please?

-- 
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 post to this group, send email to qubes-users@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/qubes-users/b8c69389-66b6-47a1-869e-0b547cdc6fe4%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.


[qubes-users] Qubes 3.2: Network doesn't connect automatically with hidden wifi

2018-02-21 Thread 'Max Andersen' via qubes-users
Hi,

I've noticed that after disabling SSID broadcast on my wifi, I need to
disable and reenable my network, every time I login.

I've tried to describe it in detail here: https://militant.dk/?p=174

Maybe anyone has ideas to resolve this?

Sincerely

Max

-- 
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 post to this group, send email to qubes-users@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/qubes-users/e8818af2-c4f9-7027-16a4-f55dcd1c410f%40militant.dk.
For more options, visit https://groups.google.com/d/optout.


[qubes-users] Re: Building Centos template conflict error?

2018-02-21 Thread fepitre
Le mardi 13 février 2018 15:47:38 UTC+1, Tim W a écrit :
> I was having issues building Centos template for 4.0 so I decided to first 
> see if it would build for 3.2.
> 
> Doing setup script templates only.  I editing example-confg 3.2 conf file and 
> removed the FC version from DISTS_VM line.
> 
> I built it per component and it fails on the last one linux-template-builder.
> os
> 
> In the centos7-template.log it shows the following conflict error
> 
> file /etc/dconf/profile/user from install of 
> qubes-core-vm-3.2.23-1.el7.centos.x86_64 conflicts with file from package 
> dconf-0.26.0-2.el7.x86_64
> 
> Ultimately I want to build these for 4.0 but figured first getting it working 
> for 3.2 as its suppose to work there already.

I solved the problem. You can track the update here: 
https://github.com/QubesOS/qubes-core-agent-linux/pull/97

I succeed to build the template in R3.2. The R4.0 is still pending...

-- 
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 post to this group, send email to qubes-users@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/qubes-users/3c36f798-e47c-4e01-9f80-b4ea3c4cce49%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.


[qubes-users] Re: [qubes-devel] Re: [qubes-announce] QSB #38: Qrexec policy bypass and possible information leak

2018-02-21 Thread billollib
On Tuesday, February 20, 2018 at 10:27:24 AM UTC-5, Tom Zander wrote:

> So, knowing that your API is actually based on 8-bit characters and not 7 
> bits which you are limiting yourself to, my suggestion is to take something 
> above 127 and below 256 as a special char.
> Most fun one would be “ÿ” which is a normal character you can pass on a 
> shell script if you must, its actual byte-value is 0xFF
> 
> -- 
> Tom Zander
> Blog: https://zander.github.io
> Vlog: https://vimeo.com/channels/tomscryptochannel



Hah!  I'm starting to have nightmares from my old days programming in APL.  
There be dragons there...

-- 
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 post to this group, send email to qubes-users@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/qubes-users/deb48d98-5523-4000-93d6-b7a1bb4b3918%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.


[qubes-users] Re: [qubes-devel] Re: [qubes-announce] QSB #38: Qrexec policy bypass and possible information leak

2018-02-21 Thread Yuraeitha
On Wednesday, February 21, 2018 at 5:41:41 PM UTC+1, qubenix wrote:
> > So let me be blunt as this is likely the last email from me to qubes
> anyway;
> 
> Bye, I'm happy to see you go away finally. It was killing me inside that
> you were working on the new gui controller. Fuck off back to bcash.
> 
> -- 
> qubenix
> GPG: B536812904D455B491DCDCDD04BE1E61A3C2E500

Not trying to understand other people a trap many fall into, even among those 
who try to understand others, we can all at times fail at it. Especially if 
something bad is going on in a persons life at the time, which can trigger an 
otherwise understanding person not to try understand another person, thereby 
igniting a conflict which wouldn't have happened otherwise. The world is 
complex.

Once the initial conflict has been ignited, personal grudges or even long 
exhausting and devastating wars, people often forget why they were even fight 
in the first place. Initial conflicts can go out of control, the lack of 
understanding being the fuel to seeking protect one self, by harming the 
opponent, instead of seeing the find the root of the issue and solving it.

Conflicts, can become self realized prophecy, what matters is to break this 
"circle" early on. It's like the butterfly effect in Chaos Theory, the first 
impression of a person can lead to very complex situations later on. If not 
taking steps to break the circle, initial conditions will then determine your 
relationship with that person. Like an unstoppable but irrational momentum.

It's not always possible to stop one self to cause more harm rather than try to 
understand the other, especially if having a bad time from something else in 
ones own life, but in the very end most people by far don't mean to harm one 
another. It's simply a lack of understanding of each others. The actual "harm" 
being done, is not the root, the lack of understanding is what leads to the 
"harming", not the other way around. 

So trying to understand is key, to not harm each others. Something we can all 
fail at, even the most peaceful humans can forget it, we all live complex lives 
with ups and downs.

It's also human nature to be lazy, it's encoded in us from evolution, and it's 
even an universal law in entropy. The entire universe, and every system in it, 
including ourselves, have incentives to be lazy and uptimize to the most 
efficient approach. Even how you walk is highly efficient, the way you conduct 
your social life is efficient. 

If one wants to break away from it, then one self needs to introduce more 
energy to the system from outside the system (entropy). And there lies the 
issue, conflicts are systems which no energy are given (or effort) to try 
understand one another. The conflict (or the system of relationship following 
the universal rules of entropy) will then exhaust itslef and burn out. Even 
relationships and marriages follow this logic.

By in an on it self, we're not channeling enough energy into this relationship, 
and thereby the relationship is suffering. By being lazy, we justify it by just 
calling the other "bad" or "evil". But in reality, very few people are actually 
such.

-- 
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 post to this group, send email to qubes-users@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/qubes-users/43cf9775-cb44-455f-ae9d-83a9cf0dfc12%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.


Re: [qubes-users] Re: [qubes-devel] Re: [qubes-announce] QSB #38: Qrexec policy bypass and possible information leak

2018-02-21 Thread haaber
On 02/21/2018 05:41 PM, qubenix wrote:
>> So let me be blunt as this is likely the last email from me to qubes
> anyway;
> 
> Bye, I'm happy to see you go away finally. It was killing me inside that
> you were working on the new gui controller. Fuck off back to bcash.
> 
I really hope that you will understand one day that the first victim of
your hate is yourself. Until this day I prefer that you keep such kind
of language out of this mailing list ... Bernhard

-- 
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 post to this group, send email to qubes-users@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/qubes-users/8bef9fe3-5fbe-8025-8885-e60bb9fe5a85%40web.de.
For more options, visit https://groups.google.com/d/optout.


[qubes-users] Re: [qubes-devel] Re: [qubes-announce] QSB #38: Qrexec policy bypass and possible information leak

2018-02-21 Thread 'awokd' via qubes-users
On Wed, February 21, 2018 4:41 pm, qubenix wrote:
>> So let me be blunt as this is likely the last email from me to qubes
>>
> anyway;
>
> Bye, I'm happy to see you go away finally. It was killing me inside that
> you were working on the new gui controller. Fuck off back to bcash.

Tom had some constructive criticism to offer, which is healthy. I don't
think your response is particularly constructive or appropriate for the
mailing lists, however.


-- 
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 post to this group, send email to qubes-users@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/qubes-users/2e43f714c9a042127c35756526d64771.squirrel%40tt3j2x4k5ycaa5zt.onion.
For more options, visit https://groups.google.com/d/optout.


[qubes-users] Re: [qubes-devel] Re: [qubes-announce] QSB #38: Qrexec policy bypass and possible information leak

2018-02-21 Thread qubenix
> So let me be blunt as this is likely the last email from me to qubes
anyway;

Bye, I'm happy to see you go away finally. It was killing me inside that
you were working on the new gui controller. Fuck off back to bcash.

-- 
qubenix
GPG: B536812904D455B491DCDCDD04BE1E61A3C2E500

-- 
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 post to this group, send email to qubes-users@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/qubes-users/2b004517-b9b8-6507-dd04-173728dc3999%40riseup.net.
For more options, visit https://groups.google.com/d/optout.


[qubes-users] Re: Standalone VMs can't reach network after restoring from backup to fresh 4.0rc4 install

2018-02-21 Thread Yuraeitha
On Wednesday, February 21, 2018 at 4:33:14 PM UTC+1, Sonny Horton wrote:
> On Wednesday, February 21, 2018 at 8:31:37 AM UTC-7, Yuraeitha wrote:
> > On Wednesday, February 21, 2018 at 4:13:55 PM UTC+1, Sonny Horton wrote:
> > > On Tuesday, February 20, 2018 at 2:45:28 PM UTC-7, Yuraeitha wrote:
> > > > On Tuesday, February 20, 2018 at 9:06:24 PM UTC+1, Sonny Horton wrote:
> > > > > On Tuesday, February 20, 2018 at 12:46:45 PM UTC-7, Yuraeitha wrote:
> > > > > > On Tuesday, February 20, 2018 at 6:59:14 PM UTC+1, Sonny Horton 
> > > > > > wrote:
> > > > > > > I was originally on R3.2 and created 5 Standalone VMs: antergos, 
> > > > > > > kali, parrotOS, Ubuntu (desktop), win7
> > > > > > > 
> > > > > > > I upgraded along the way to various R4.0 release candidates.  I 
> > > > > > > skipped rc1 as it was not usable on my hardware.  rc2 was usable 
> > > > > > > with some work, and rc3 has been working great.  At each upgrade 
> > > > > > > through rc3, I used backups of the Standalone VMs that were 
> > > > > > > created in 3.2.
> > > > > > > 
> > > > > > > However, When I decided to take the rc4 plunge, I took fresh 
> > > > > > > backups of the VMs from R4.0rc3.
> > > > > > > 
> > > > > > > All 5 VMs restored cleanly (although slowly) from backup and all 
> > > > > > > operate normally, except:
> > > > > > > 
> > > > > > > None of the 5 VMs have access to the network - at all (neither 
> > > > > > > browser nor ping - either by name or IP).
> > > > > > > 
> > > > > > > I've done the following:
> > > > > > > 
> > > > > > > Made sure that each of the VMs is using sys-firewall as its netvm.
> > > > > > > 
> > > > > > > Made sure that I can reach the network from sys-firewall (using 
> > > > > > > both command line [ping] and browser tools).
> > > > > > > 
> > > > > > > Made sure each Standalone VM is in PVH mode (except win7, which I 
> > > > > > > have tried both as PVH and HVM).
> > > > > > > 
> > > > > > > Made sure no exclusive firewall rules are in place (allow all 
> > > > > > > outbound traffic is selected).
> > > > > > > 
> > > > > > > Double-checked to make sure that the new rc4 template VMs are 
> > > > > > > able to connect to the network - they all are.  Note that the 
> > > > > > > Standalone VMs are the ONLY ones I restored from rc3 - not any 
> > > > > > > template VMs or VMs derived from templates.
> > > > > > > 
> > > > > > > Note that the state indicator in Qube Manager is yellow for each 
> > > > > > > of these Standalone VMs when they are running.  I couldn't find a 
> > > > > > > legend for this, but assume it is not as good as green :)
> > > > > > > 
> > > > > > > 
> > > > > > > I am still a bit of a novice Qubes user, but rather competent 
> > > > > > > otherwise.  I would welcome any informed direction on where to 
> > > > > > > take my troubleshooting next.  My goal is to get these 5 VMs 
> > > > > > > running with network access one rc4, especially the kali and 
> > > > > > > parrotOS VMs, which are fairly customized setups.  The others are 
> > > > > > > quite generic and are for testing.
> > > > > > > 
> > > > > > > Thanks in advance for your help!
> > > > > > > 
> > > > > > > Sonny Horton
> > > > > > 
> > > > > > Could it by any chance be that this is a similar issue to that of 
> > > > > > standalone Windows in Qubes 4, where the old Qubes tools network 
> > > > > > service is broken? The solution there is to disable the Qubes 
> > > > > > network service inside Windows, and then manually set the 
> > > > > > IP/subnet/Gateway/QubesDNS. Perhaps something similar has to be 
> > > > > > done in these other standalone VM's now?
> > > > > > 
> > > > > > Windows has to be run in HVM mode though (PV probably works too, 
> > > > > > but at least PVH is officially confirmed not to work with Windows 
> > > > > > 7).
> > > > > > 
> > > > > > Did you try click on the VM in the Qube Manager to see if the 
> > > > > > yellow indicator changes? You might know this already, but the Qube 
> > > > > > Manager is "somewhat" frozen in Qubes 4, or at the very least so 
> > > > > > slow that it appears frozen. For example if you start a VM, or 
> > > > > > close a VM, while the Qube Manager window is up, then it won't 
> > > > > > update the new status. Similar, if you start th Qube Manager while 
> > > > > > your VM's are starting up or shutting down, then they will show 
> > > > > > yellow, which they also did back in Qubes 3.2. during start or stop 
> > > > > > of VM's. I think it's a little better with recent updates though, 
> > > > > > if you click on the individual VM's in the window, then the status 
> > > > > > will update upon the click. Maybe it happens automatically if more 
> > > > > > patient? I never use the Qube Manager anymore, so I'm not sure how 
> > > > > > its behavior changes after each update. Maybe it behaves different 
> > > > > > in Q4 RC-4? A re-install was announced not to be necessary between 
> > > > > > RC-3 and RC-4 in the release news, but there are still some small 

[qubes-users] Re: Standalone VMs can't reach network after restoring from backup to fresh 4.0rc4 install

2018-02-21 Thread Sonny Horton
On Wednesday, February 21, 2018 at 8:31:37 AM UTC-7, Yuraeitha wrote:
> On Wednesday, February 21, 2018 at 4:13:55 PM UTC+1, Sonny Horton wrote:
> > On Tuesday, February 20, 2018 at 2:45:28 PM UTC-7, Yuraeitha wrote:
> > > On Tuesday, February 20, 2018 at 9:06:24 PM UTC+1, Sonny Horton wrote:
> > > > On Tuesday, February 20, 2018 at 12:46:45 PM UTC-7, Yuraeitha wrote:
> > > > > On Tuesday, February 20, 2018 at 6:59:14 PM UTC+1, Sonny Horton wrote:
> > > > > > I was originally on R3.2 and created 5 Standalone VMs: antergos, 
> > > > > > kali, parrotOS, Ubuntu (desktop), win7
> > > > > > 
> > > > > > I upgraded along the way to various R4.0 release candidates.  I 
> > > > > > skipped rc1 as it was not usable on my hardware.  rc2 was usable 
> > > > > > with some work, and rc3 has been working great.  At each upgrade 
> > > > > > through rc3, I used backups of the Standalone VMs that were created 
> > > > > > in 3.2.
> > > > > > 
> > > > > > However, When I decided to take the rc4 plunge, I took fresh 
> > > > > > backups of the VMs from R4.0rc3.
> > > > > > 
> > > > > > All 5 VMs restored cleanly (although slowly) from backup and all 
> > > > > > operate normally, except:
> > > > > > 
> > > > > > None of the 5 VMs have access to the network - at all (neither 
> > > > > > browser nor ping - either by name or IP).
> > > > > > 
> > > > > > I've done the following:
> > > > > > 
> > > > > > Made sure that each of the VMs is using sys-firewall as its netvm.
> > > > > > 
> > > > > > Made sure that I can reach the network from sys-firewall (using 
> > > > > > both command line [ping] and browser tools).
> > > > > > 
> > > > > > Made sure each Standalone VM is in PVH mode (except win7, which I 
> > > > > > have tried both as PVH and HVM).
> > > > > > 
> > > > > > Made sure no exclusive firewall rules are in place (allow all 
> > > > > > outbound traffic is selected).
> > > > > > 
> > > > > > Double-checked to make sure that the new rc4 template VMs are able 
> > > > > > to connect to the network - they all are.  Note that the Standalone 
> > > > > > VMs are the ONLY ones I restored from rc3 - not any template VMs or 
> > > > > > VMs derived from templates.
> > > > > > 
> > > > > > Note that the state indicator in Qube Manager is yellow for each of 
> > > > > > these Standalone VMs when they are running.  I couldn't find a 
> > > > > > legend for this, but assume it is not as good as green :)
> > > > > > 
> > > > > > 
> > > > > > I am still a bit of a novice Qubes user, but rather competent 
> > > > > > otherwise.  I would welcome any informed direction on where to take 
> > > > > > my troubleshooting next.  My goal is to get these 5 VMs running 
> > > > > > with network access one rc4, especially the kali and parrotOS VMs, 
> > > > > > which are fairly customized setups.  The others are quite generic 
> > > > > > and are for testing.
> > > > > > 
> > > > > > Thanks in advance for your help!
> > > > > > 
> > > > > > Sonny Horton
> > > > > 
> > > > > Could it by any chance be that this is a similar issue to that of 
> > > > > standalone Windows in Qubes 4, where the old Qubes tools network 
> > > > > service is broken? The solution there is to disable the Qubes network 
> > > > > service inside Windows, and then manually set the 
> > > > > IP/subnet/Gateway/QubesDNS. Perhaps something similar has to be done 
> > > > > in these other standalone VM's now?
> > > > > 
> > > > > Windows has to be run in HVM mode though (PV probably works too, but 
> > > > > at least PVH is officially confirmed not to work with Windows 7).
> > > > > 
> > > > > Did you try click on the VM in the Qube Manager to see if the yellow 
> > > > > indicator changes? You might know this already, but the Qube Manager 
> > > > > is "somewhat" frozen in Qubes 4, or at the very least so slow that it 
> > > > > appears frozen. For example if you start a VM, or close a VM, while 
> > > > > the Qube Manager window is up, then it won't update the new status. 
> > > > > Similar, if you start th Qube Manager while your VM's are starting up 
> > > > > or shutting down, then they will show yellow, which they also did 
> > > > > back in Qubes 3.2. during start or stop of VM's. I think it's a 
> > > > > little better with recent updates though, if you click on the 
> > > > > individual VM's in the window, then the status will update upon the 
> > > > > click. Maybe it happens automatically if more patient? I never use 
> > > > > the Qube Manager anymore, so I'm not sure how its behavior changes 
> > > > > after each update. Maybe it behaves different in Q4 RC-4? A 
> > > > > re-install was announced not to be necessary between RC-3 and RC-4 in 
> > > > > the release news, but there are still some small variations though, 
> > > > > perhaps the Qube Manager is quicker in RC-4? At least for me, it's 
> > > > > very slow, and it appears frozen. 
> > > > > 
> > > > > With the standalone VM issue, manual configuration of IP's is the 
> > > > > only suggestion that I 

[qubes-users] Re: Standalone VMs can't reach network after restoring from backup to fresh 4.0rc4 install

2018-02-21 Thread Yuraeitha
On Wednesday, February 21, 2018 at 4:13:55 PM UTC+1, Sonny Horton wrote:
> On Tuesday, February 20, 2018 at 2:45:28 PM UTC-7, Yuraeitha wrote:
> > On Tuesday, February 20, 2018 at 9:06:24 PM UTC+1, Sonny Horton wrote:
> > > On Tuesday, February 20, 2018 at 12:46:45 PM UTC-7, Yuraeitha wrote:
> > > > On Tuesday, February 20, 2018 at 6:59:14 PM UTC+1, Sonny Horton wrote:
> > > > > I was originally on R3.2 and created 5 Standalone VMs: antergos, 
> > > > > kali, parrotOS, Ubuntu (desktop), win7
> > > > > 
> > > > > I upgraded along the way to various R4.0 release candidates.  I 
> > > > > skipped rc1 as it was not usable on my hardware.  rc2 was usable with 
> > > > > some work, and rc3 has been working great.  At each upgrade through 
> > > > > rc3, I used backups of the Standalone VMs that were created in 3.2.
> > > > > 
> > > > > However, When I decided to take the rc4 plunge, I took fresh backups 
> > > > > of the VMs from R4.0rc3.
> > > > > 
> > > > > All 5 VMs restored cleanly (although slowly) from backup and all 
> > > > > operate normally, except:
> > > > > 
> > > > > None of the 5 VMs have access to the network - at all (neither 
> > > > > browser nor ping - either by name or IP).
> > > > > 
> > > > > I've done the following:
> > > > > 
> > > > > Made sure that each of the VMs is using sys-firewall as its netvm.
> > > > > 
> > > > > Made sure that I can reach the network from sys-firewall (using both 
> > > > > command line [ping] and browser tools).
> > > > > 
> > > > > Made sure each Standalone VM is in PVH mode (except win7, which I 
> > > > > have tried both as PVH and HVM).
> > > > > 
> > > > > Made sure no exclusive firewall rules are in place (allow all 
> > > > > outbound traffic is selected).
> > > > > 
> > > > > Double-checked to make sure that the new rc4 template VMs are able to 
> > > > > connect to the network - they all are.  Note that the Standalone VMs 
> > > > > are the ONLY ones I restored from rc3 - not any template VMs or VMs 
> > > > > derived from templates.
> > > > > 
> > > > > Note that the state indicator in Qube Manager is yellow for each of 
> > > > > these Standalone VMs when they are running.  I couldn't find a legend 
> > > > > for this, but assume it is not as good as green :)
> > > > > 
> > > > > 
> > > > > I am still a bit of a novice Qubes user, but rather competent 
> > > > > otherwise.  I would welcome any informed direction on where to take 
> > > > > my troubleshooting next.  My goal is to get these 5 VMs running with 
> > > > > network access one rc4, especially the kali and parrotOS VMs, which 
> > > > > are fairly customized setups.  The others are quite generic and are 
> > > > > for testing.
> > > > > 
> > > > > Thanks in advance for your help!
> > > > > 
> > > > > Sonny Horton
> > > > 
> > > > Could it by any chance be that this is a similar issue to that of 
> > > > standalone Windows in Qubes 4, where the old Qubes tools network 
> > > > service is broken? The solution there is to disable the Qubes network 
> > > > service inside Windows, and then manually set the 
> > > > IP/subnet/Gateway/QubesDNS. Perhaps something similar has to be done in 
> > > > these other standalone VM's now?
> > > > 
> > > > Windows has to be run in HVM mode though (PV probably works too, but at 
> > > > least PVH is officially confirmed not to work with Windows 7).
> > > > 
> > > > Did you try click on the VM in the Qube Manager to see if the yellow 
> > > > indicator changes? You might know this already, but the Qube Manager is 
> > > > "somewhat" frozen in Qubes 4, or at the very least so slow that it 
> > > > appears frozen. For example if you start a VM, or close a VM, while the 
> > > > Qube Manager window is up, then it won't update the new status. 
> > > > Similar, if you start th Qube Manager while your VM's are starting up 
> > > > or shutting down, then they will show yellow, which they also did back 
> > > > in Qubes 3.2. during start or stop of VM's. I think it's a little 
> > > > better with recent updates though, if you click on the individual VM's 
> > > > in the window, then the status will update upon the click. Maybe it 
> > > > happens automatically if more patient? I never use the Qube Manager 
> > > > anymore, so I'm not sure how its behavior changes after each update. 
> > > > Maybe it behaves different in Q4 RC-4? A re-install was announced not 
> > > > to be necessary between RC-3 and RC-4 in the release news, but there 
> > > > are still some small variations though, perhaps the Qube Manager is 
> > > > quicker in RC-4? At least for me, it's very slow, and it appears 
> > > > frozen. 
> > > > 
> > > > With the standalone VM issue, manual configuration of IP's is the only 
> > > > suggestion that I can think of. If you already tried that or it doesn't 
> > > > work, then best wait for someone who knows more, I can only offer Qubes 
> > > > trial and error suggestions at best.
> > > 
> > > Initially followed my ignorant reflexes and replied to the 

[qubes-users] Re: Standalone VMs can't reach network after restoring from backup to fresh 4.0rc4 install

2018-02-21 Thread Sonny Horton
On Wednesday, February 21, 2018 at 8:13:55 AM UTC-7, Sonny Horton wrote:
> On Tuesday, February 20, 2018 at 2:45:28 PM UTC-7, Yuraeitha wrote:
> > On Tuesday, February 20, 2018 at 9:06:24 PM UTC+1, Sonny Horton wrote:
> > > On Tuesday, February 20, 2018 at 12:46:45 PM UTC-7, Yuraeitha wrote:
> > > > On Tuesday, February 20, 2018 at 6:59:14 PM UTC+1, Sonny Horton wrote:
> > > > > I was originally on R3.2 and created 5 Standalone VMs: antergos, 
> > > > > kali, parrotOS, Ubuntu (desktop), win7
> > > > > 
> > > > > I upgraded along the way to various R4.0 release candidates.  I 
> > > > > skipped rc1 as it was not usable on my hardware.  rc2 was usable with 
> > > > > some work, and rc3 has been working great.  At each upgrade through 
> > > > > rc3, I used backups of the Standalone VMs that were created in 3.2.
> > > > > 
> > > > > However, When I decided to take the rc4 plunge, I took fresh backups 
> > > > > of the VMs from R4.0rc3.
> > > > > 
> > > > > All 5 VMs restored cleanly (although slowly) from backup and all 
> > > > > operate normally, except:
> > > > > 
> > > > > None of the 5 VMs have access to the network - at all (neither 
> > > > > browser nor ping - either by name or IP).
> > > > > 
> > > > > I've done the following:
> > > > > 
> > > > > Made sure that each of the VMs is using sys-firewall as its netvm.
> > > > > 
> > > > > Made sure that I can reach the network from sys-firewall (using both 
> > > > > command line [ping] and browser tools).
> > > > > 
> > > > > Made sure each Standalone VM is in PVH mode (except win7, which I 
> > > > > have tried both as PVH and HVM).
> > > > > 
> > > > > Made sure no exclusive firewall rules are in place (allow all 
> > > > > outbound traffic is selected).
> > > > > 
> > > > > Double-checked to make sure that the new rc4 template VMs are able to 
> > > > > connect to the network - they all are.  Note that the Standalone VMs 
> > > > > are the ONLY ones I restored from rc3 - not any template VMs or VMs 
> > > > > derived from templates.
> > > > > 
> > > > > Note that the state indicator in Qube Manager is yellow for each of 
> > > > > these Standalone VMs when they are running.  I couldn't find a legend 
> > > > > for this, but assume it is not as good as green :)
> > > > > 
> > > > > 
> > > > > I am still a bit of a novice Qubes user, but rather competent 
> > > > > otherwise.  I would welcome any informed direction on where to take 
> > > > > my troubleshooting next.  My goal is to get these 5 VMs running with 
> > > > > network access one rc4, especially the kali and parrotOS VMs, which 
> > > > > are fairly customized setups.  The others are quite generic and are 
> > > > > for testing.
> > > > > 
> > > > > Thanks in advance for your help!
> > > > > 
> > > > > Sonny Horton
> > > > 
> > > > Could it by any chance be that this is a similar issue to that of 
> > > > standalone Windows in Qubes 4, where the old Qubes tools network 
> > > > service is broken? The solution there is to disable the Qubes network 
> > > > service inside Windows, and then manually set the 
> > > > IP/subnet/Gateway/QubesDNS. Perhaps something similar has to be done in 
> > > > these other standalone VM's now?
> > > > 
> > > > Windows has to be run in HVM mode though (PV probably works too, but at 
> > > > least PVH is officially confirmed not to work with Windows 7).
> > > > 
> > > > Did you try click on the VM in the Qube Manager to see if the yellow 
> > > > indicator changes? You might know this already, but the Qube Manager is 
> > > > "somewhat" frozen in Qubes 4, or at the very least so slow that it 
> > > > appears frozen. For example if you start a VM, or close a VM, while the 
> > > > Qube Manager window is up, then it won't update the new status. 
> > > > Similar, if you start th Qube Manager while your VM's are starting up 
> > > > or shutting down, then they will show yellow, which they also did back 
> > > > in Qubes 3.2. during start or stop of VM's. I think it's a little 
> > > > better with recent updates though, if you click on the individual VM's 
> > > > in the window, then the status will update upon the click. Maybe it 
> > > > happens automatically if more patient? I never use the Qube Manager 
> > > > anymore, so I'm not sure how its behavior changes after each update. 
> > > > Maybe it behaves different in Q4 RC-4? A re-install was announced not 
> > > > to be necessary between RC-3 and RC-4 in the release news, but there 
> > > > are still some small variations though, perhaps the Qube Manager is 
> > > > quicker in RC-4? At least for me, it's very slow, and it appears 
> > > > frozen. 
> > > > 
> > > > With the standalone VM issue, manual configuration of IP's is the only 
> > > > suggestion that I can think of. If you already tried that or it doesn't 
> > > > work, then best wait for someone who knows more, I can only offer Qubes 
> > > > trial and error suggestions at best.
> > > 
> > > Initially followed my ignorant reflexes and replied to the 

[qubes-users] Re: Standalone VMs can't reach network after restoring from backup to fresh 4.0rc4 install

2018-02-21 Thread Sonny Horton
On Tuesday, February 20, 2018 at 2:45:28 PM UTC-7, Yuraeitha wrote:
> On Tuesday, February 20, 2018 at 9:06:24 PM UTC+1, Sonny Horton wrote:
> > On Tuesday, February 20, 2018 at 12:46:45 PM UTC-7, Yuraeitha wrote:
> > > On Tuesday, February 20, 2018 at 6:59:14 PM UTC+1, Sonny Horton wrote:
> > > > I was originally on R3.2 and created 5 Standalone VMs: antergos, kali, 
> > > > parrotOS, Ubuntu (desktop), win7
> > > > 
> > > > I upgraded along the way to various R4.0 release candidates.  I skipped 
> > > > rc1 as it was not usable on my hardware.  rc2 was usable with some 
> > > > work, and rc3 has been working great.  At each upgrade through rc3, I 
> > > > used backups of the Standalone VMs that were created in 3.2.
> > > > 
> > > > However, When I decided to take the rc4 plunge, I took fresh backups of 
> > > > the VMs from R4.0rc3.
> > > > 
> > > > All 5 VMs restored cleanly (although slowly) from backup and all 
> > > > operate normally, except:
> > > > 
> > > > None of the 5 VMs have access to the network - at all (neither browser 
> > > > nor ping - either by name or IP).
> > > > 
> > > > I've done the following:
> > > > 
> > > > Made sure that each of the VMs is using sys-firewall as its netvm.
> > > > 
> > > > Made sure that I can reach the network from sys-firewall (using both 
> > > > command line [ping] and browser tools).
> > > > 
> > > > Made sure each Standalone VM is in PVH mode (except win7, which I have 
> > > > tried both as PVH and HVM).
> > > > 
> > > > Made sure no exclusive firewall rules are in place (allow all outbound 
> > > > traffic is selected).
> > > > 
> > > > Double-checked to make sure that the new rc4 template VMs are able to 
> > > > connect to the network - they all are.  Note that the Standalone VMs 
> > > > are the ONLY ones I restored from rc3 - not any template VMs or VMs 
> > > > derived from templates.
> > > > 
> > > > Note that the state indicator in Qube Manager is yellow for each of 
> > > > these Standalone VMs when they are running.  I couldn't find a legend 
> > > > for this, but assume it is not as good as green :)
> > > > 
> > > > 
> > > > I am still a bit of a novice Qubes user, but rather competent 
> > > > otherwise.  I would welcome any informed direction on where to take my 
> > > > troubleshooting next.  My goal is to get these 5 VMs running with 
> > > > network access one rc4, especially the kali and parrotOS VMs, which are 
> > > > fairly customized setups.  The others are quite generic and are for 
> > > > testing.
> > > > 
> > > > Thanks in advance for your help!
> > > > 
> > > > Sonny Horton
> > > 
> > > Could it by any chance be that this is a similar issue to that of 
> > > standalone Windows in Qubes 4, where the old Qubes tools network service 
> > > is broken? The solution there is to disable the Qubes network service 
> > > inside Windows, and then manually set the IP/subnet/Gateway/QubesDNS. 
> > > Perhaps something similar has to be done in these other standalone VM's 
> > > now?
> > > 
> > > Windows has to be run in HVM mode though (PV probably works too, but at 
> > > least PVH is officially confirmed not to work with Windows 7).
> > > 
> > > Did you try click on the VM in the Qube Manager to see if the yellow 
> > > indicator changes? You might know this already, but the Qube Manager is 
> > > "somewhat" frozen in Qubes 4, or at the very least so slow that it 
> > > appears frozen. For example if you start a VM, or close a VM, while the 
> > > Qube Manager window is up, then it won't update the new status. Similar, 
> > > if you start th Qube Manager while your VM's are starting up or shutting 
> > > down, then they will show yellow, which they also did back in Qubes 3.2. 
> > > during start or stop of VM's. I think it's a little better with recent 
> > > updates though, if you click on the individual VM's in the window, then 
> > > the status will update upon the click. Maybe it happens automatically if 
> > > more patient? I never use the Qube Manager anymore, so I'm not sure how 
> > > its behavior changes after each update. Maybe it behaves different in Q4 
> > > RC-4? A re-install was announced not to be necessary between RC-3 and 
> > > RC-4 in the release news, but there are still some small variations 
> > > though, perhaps the Qube Manager is quicker in RC-4? At least for me, 
> > > it's very slow, and it appears frozen. 
> > > 
> > > With the standalone VM issue, manual configuration of IP's is the only 
> > > suggestion that I can think of. If you already tried that or it doesn't 
> > > work, then best wait for someone who knows more, I can only offer Qubes 
> > > trial and error suggestions at best.
> > 
> > Initially followed my ignorant reflexes and replied to the e-mail, sorry!
> > 
> > @yuraeitha - thank you for the reply.
> > 
> > I’ve had the win7 VM working in R4.0rc3 with networking, having applied the 
> > qubes tools fix [IIRC it was a simple reinstall of tools], so I don’t 
> > believe this to be the issue.
> > 

[qubes-users] Re: How to delete or upgrade app VMs?

2018-02-21 Thread Yuraeitha
On Wednesday, February 21, 2018 at 5:48:24 AM UTC+1, Kyle Breneman wrote:
> I'm running Qubes 3.2.  I have the default Fedora 23 template VM, and the 
> default app VMs built from it, but I also installed a Fedora 26 template VM.  
> Now I want to delete or upgrade my Fedora 23 app VMs, but I cannot figure out 
> how to do this.  The "Delete VM" menu option in the Qubes VM Manager always 
> seems to be grayed-out.  How can I either delete these app VMs based on 
> Fedora 23, or switch them over to my Fedora 26 template?
> 
> 
> Regards,
> 
> Kyle

uh, that guide confuses even me who knows the steps >.< not everyone think the 
same way, so I'll put a different perspective below.

In broad sense, there are two major steps you need to do, which won't take long.
- Change (untie) any AppVM's that use the template, to your new template.
- Then, and only then, can you delete a template once it's untied from any 
AppVM''s. 

It's that easy, pretty straight forward. But be warned not to confuse when to 
use dnf remove and qvm-remove, more on that below.



On how to do this;
Right click on desktop and open your dom0 Terminal, write in "qvm-ls", drag the 
window a bit larger so you can better see the table. Any AppVM's still using 
the old template will show here.

Once you're done moving templates over to your new template, write in dom0 
"Qubes-Global-Settings"and check if the old template isn't being listed here, 
if it is, change it to the new template instead. 

Default system templates, which include both does pre-installed or the ones you 
download with the command you used, can be removed with "sudo dnf remove 
qubes-template-fedora-23". 

It's here very important that you distinguish between dnf remove and 
qvm-remote, as it can mess up your system. Only use qvm-remove on regular 
AppVM's or cloned templates (cloned templates, the ones you cloned and copied 
yourself). Qvm-remove may also be needed on some standalone VM's, but it's a 
less frequent situation.

In order to remove a default template, such as fedora, debian, whonix, you need 
to use the dnf remove command, but first, you need to completely untie your old 
fedora version, as shown above. If you're unsure how to untie them, it's pretty 
straight forward, just go to each VM's GUI Settings, and change the template in 
the first tab window, and that's it. You may want to verify if the AppVM works 
before you delete the old template though.

Qubes is very modular in this sense, it's a smart build. Simply by untying to 
the templates, and it'll become delete-able. 

-- 
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 post to this group, send email to qubes-users@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/qubes-users/7f3198ef-31c7-4054-99dc-526c489eedf3%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.


[qubes-users] Proxy/firewall VM with template fedora-26-minimal non-functional

2018-02-21 Thread mittendorf
I downloaded the fedora-2*6*-minimal to replace the fedora-2*5*-minimal.
replacing my sys-firewall equivalent the connected AppVMs can no longer
connect to the internet. If I return to the fedora-25-minimal template,
everything is working fine again.

Is there an issue with the fedora-26-minimal template that you provide?

There was no issue migrating from 24-minimal to 25-minimal and according to

https://www.qubes-os.org/doc/templates/fedora-minimal/

the minimal template can be used as a sys-firewall without any changes

-- 
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 post to this group, send email to qubes-users@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/qubes-users/88df86b3-be06-9089-0c1d-75ed50f7b81c%40digitrace.de.
For more options, visit https://groups.google.com/d/optout.


Re: [qubes-users] Linux VMs can't reach network after restoring from backup to fresh 4.0rc3 install

2018-02-21 Thread 'awokd' via qubes-users
On Wed, February 21, 2018 11:18 am, ThierryIT wrote:
> Le mercredi 21 février 2018 12:31:29 UTC+2, awokd a écrit :

>> Usually there is a script that runs inside the Linux VM that re-assigns
>>  these to the correct values, but since it's been restored from R3.2 it
>>  might not be working. From within vm-work, try assigning the above
>> values manually. Check another working VM for the appropriate DNS
>> settings.
>
> Seems not able to keep the manual network config ... Is the internal
> script can re-write the config ?

Possibly, I don't exactly know how it works.

> I have add the folder "eth0" in "interfaces.d" -> doesn't keep the config
>  or I have add the network config to the file "interfaces"

Instead of trying to fix this broken HVM, maybe it would be best to create
a new "work" AppVM based on a Fedora template (since it sounds like that
was your plan in the first place) and to use qvm-copy-to-vm commands to
copy your data from the old to the new?


-- 
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 post to this group, send email to qubes-users@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/qubes-users/b8c749a5e311ea3599cc21c9e582379d.squirrel%40tt3j2x4k5ycaa5zt.onion.
For more options, visit https://groups.google.com/d/optout.


[qubes-users] Re: [qubes-devel] Re: [qubes-announce] QSB #38: Qrexec policy bypass and possible information leak

2018-02-21 Thread 'Tom Zander' via qubes-users
On Wednesday, 21 February 2018 12:12:06 CET Wojtek Porczyk wrote:
>  This is bad UX.

This is frustrating, I spent too many emails making the point clear that 
this is an API level escape token. Not a user-visible one, and then you 
respond to the thread showing you still completely missed that.

So let me be blunt as this is likely the last email from me to qubes anyway;

Fact: Variables given to qrexec are going to be replaced with the actual 
relevant value.
For instance bash takes`ls *` and replaces the star with the actual values 
_before_ calling ls. Ls or any executable does not have to deal with things 
like star or dollar sign etc.

Your and Marek complaints are that you need to escape the variables when you 
pass them on to the target VM handler.
If you are indeed doing that, you are doing it wrong and you can wait for 
the next security bulletin like the one we are discussing right now.

The point of a variable that is passed from a VM to the dom0 qrexec daemon 
is that your source VM doesn't have to know about who is $adminVM or what is 
the actually started dispVM's name.
QRexec daemon (in dom0) should do the variable replacement before the user 
request leaves qrexec-daemon running in dom0.
Just like bash does the replacement before it forwards the command-line.


Again, if you do not do the variable replacement there, but instead pass it 
through unvalidated and unrelated software, you are going to continue having 
security flaws.

-- 
Tom Zander
Blog: https://zander.github.io
Vlog: https://vimeo.com/channels/tomscryptochannel


-- 
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 post to this group, send email to qubes-users@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/qubes-users/3526761.85MCzvWFfn%40strawberry.
For more options, visit https://groups.google.com/d/optout.


Re: [qubes-users] Linux VMs can't reach network after restoring from backup to fresh 4.0rc3 install

2018-02-21 Thread ThierryIT
Le mercredi 21 février 2018 12:31:29 UTC+2, awokd a écrit :
> On Wed, February 21, 2018 10:16 am, ThierryIT wrote:
> 
> >
> > the not working VM prefs:
> >
> 
> From these lines in your config, it looks like you've created this VM on
> R3.2 as a standalone HVM instead of an AppVM based on a template. Does
> that sound right?
> 
> klass   D  TemplateVM
> virt_mode   -  hvm
> 
> These are the network settings assigned to this VM. They have probably
> changed from what they were in R3.2:
> 
> visible_gateway D  10.137.0.18
> visible_gateway6D
> visible_ip  D  10.137.0.11
> visible_ip6 D
> visible_netmask D  255.255.255.255
> 
> Usually there is a script that runs inside the Linux VM that re-assigns
> these to the correct values, but since it's been restored from R3.2 it
> might not be working. From within vm-work, try assigning the above values
> manually. Check another working VM for the appropriate DNS settings.

Seems not able to keep the manual network config ... Is the internal script can 
re-write the config ?

I have add the folder "eth0" in "interfaces.d" -> doesn't keep the config
or 
I have add the network config to the file "interfaces"

thx

-- 
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 post to this group, send email to qubes-users@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/qubes-users/1a5af95f-2df8-442e-8aa4-d1f5ae45acc7%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.


[qubes-users] Re: [qubes-devel] Re: [qubes-announce] QSB #38: Qrexec policy bypass and possible information leak

2018-02-21 Thread Wojtek Porczyk
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

On Tue, Feb 20, 2018 at 04:27:16PM +0100, Tom Zander wrote:
> On Tuesday, 20 February 2018 14:04:03 CET Wojtek Porczyk wrote:
> > On Tue, Feb 20, 2018 at 01:21:30PM +0100, 'Tom Zander' via qubes-devel 
> wrote:
> > > On Tuesday, 20 February 2018 01:49:37 CET Marek Marczykowski-Górecki 
> wrote:
> > > > We've decided to deprecate the '$' character from qrexec-related
> > > > usage.
> > > > Instead, to denote special tokens, we will use the '@' character,
> > > > which we believe is less likely to be interpreted in a special way
> > > > by the relevant software.
> > > 
> > > I would argue against the @ sign on account that it is a special
> > > character in bash as well.
> > > 
> > > I don't immediately see a way to exploit it, but why risk it?
> > 
> > We absolutely need a special character that is not allowed in qube name to
> > make the special tokens immediately obvious in policy. The process I used
> > was to list available characters (POSIX Portable Character Set [1])
> []
> > If I missed something, could you please point out? I know shell just good
> > enough to know that it's not possible to know every shell quirk. :)
> 
> The thing you have to rememeber is that the escape character never needs to 
> be typed by the user.
> In QRexec you are defining an API, applications like qvm-run are using that 
> API. What the user passes into qvm-run and what is actually sent to dom0 
> does not have to be identical.
> I guess you do the translation currently as well; '$' turns into '@' in your 
> new code.
> 
> The consequence of this is that you don't have to limit yourself to the 
> posix list.
> Using the portable characters set for a non-character simply isn't needed.
> 
> So, knowing that your API is actually based on 8-bit characters and not 7 
> bits which you are limiting yourself to, my suggestion is to take something 
> above 127 and below 256 as a special char.
> Most fun one would be “ÿ” which is a normal character you can pass on a 
> shell script if you must, its actual byte-value is 0xFF

Thank you for the suggestion, but I don't think it's correct.

The character has to be input in at least two places: in /etc/qubes-rpc/policy
as the second token (destination) on the line and as argument to
qrexec-client[-vm] executable. Using any of the common editors, any
language-specific keyboard layout, and any common encoding. Most people have
UTF-8, or ISO-8859-*, but we don't exclude the possibility to have admin qube
on Windows -- there was at least one serious attempt -- so this brings UTF-16
and Windows-125*.

As and example, may I use ÿ character you provided:
1) You're right the codepoint is U+00FF, but UTF-8 encoding is actually
"\xc3\xbf", so no, we cannot use it.
2) I don't have it on my keyboard. So anytime I have to input one of those
characters, I search all the modifiers for the right one (ý? no. ŷ? neither.
ỹ? my font has trouble with that, is that even a letter? ý? tried this one
already...). I don't have real data, but I think most people don't even know
where to start looking for this and in the optimistic case will end up
sourcing it from gucharmap or equivalent. This is bad UX.

Maybe there is a character outside portable charset that is portable and
writable enough, but I don't know of any. I haven't thought there is hope
enough to actually find one, so I didn't bother searching. That's why I've
asked.


Again, thanks for your review. I think it's helpful, because this change was
made behind community's back (for obvious reasons), fast, and in very limited
group of people. I wasn't sure if we didn't make some mistake, so the best
what I could hope for was to explain myself and get ex post facto review,
which you provided.


- -- 
pozdrawiam / best regards   _.-._
Wojtek Porczyk   .-^'   '^-.
Invisible Things Lab |'-.-^-.-'|
 |  |   |  |
 I do not fear computers,|  '-.-'  |
 I fear lack of them.'-._ :  ,-'
-- Isaac Asimov `^-^-_>
-BEGIN PGP SIGNATURE-
Version: GnuPG v2

iQIcBAEBCAAGBQJajVQEAAoJEL9r2TIQOiNRpbUQAJjEEAk+rKZOrFjjMkG3WQem
/KNCL9gfVt3T6/keBBuEwfX3XcOIiO/FBWNfcf6dxeBGGcMHHQn0pd4Ucj/HZw8b
0/s63gjXH+ru7m4x2VW/3uDI4igkic6UUYPVHDB0sQtbTvGGWsr5pPJxcx7JgbwX
+mJmDgt7i/9Y3lAGEva5ex+q7WG4hJd8ArgnJGAVnp7MrTgIduHW1/2QufC6uvvE
gRRc3gbZK5FkT5Yg38UumE4sNcmnV0Nvu3m+o/g/cBcEER7wO81XW6TKFj0Ok/Bg
Ostsov9NwO3iGv0usSUvMKfw7Aac3VK9SsW0r5sxA/QFe9jVvasVnmvIrxTRwwL+
W+gP5piagxgphLhUcR6LwyEhRPWzb06iDaaztXnLXyInWFEGdei1ATmlQNI0Rmno
pNh/QLQqS6YF+hAl8LxSkOj3tjcg7MTYl00y9Z6ePJRUDA84s1hlWT43agWNN4L3
SX55/UzTU8DlhcduL3WmY6DVIKKlfE2Q82VorkprY6i/u/d7fdCblYLOtatZh2JB
OK1ZFOprRlAJodYQMUws7o8cDgY3LxfgKX45PC23DJG6o5CDM+WoqmUw72uxMFft
jRE299HwUV3qfzxm9/bjLPJqgnP+nSFnY/4J02iHUQxkg3Xb9ibKxFmTWhnf78zd
REwcpFmrrjnrVVy14CZ2
=wkxM
-END PGP SIGNATURE-

-- 
You received this message because you are subscribed to the Google Groups 
"qubes-users" group.
To unsubscribe from this 

Re: [qubes-users] Linux VMs can't reach network after restoring from backup to fresh 4.0rc3 install

2018-02-21 Thread 'awokd' via qubes-users
On Wed, February 21, 2018 10:16 am, ThierryIT wrote:

>
> the not working VM prefs:
>

>From these lines in your config, it looks like you've created this VM on
R3.2 as a standalone HVM instead of an AppVM based on a template. Does
that sound right?

klass   D  TemplateVM
virt_mode   -  hvm

These are the network settings assigned to this VM. They have probably
changed from what they were in R3.2:

visible_gateway D  10.137.0.18
visible_gateway6D
visible_ip  D  10.137.0.11
visible_ip6 D
visible_netmask D  255.255.255.255

Usually there is a script that runs inside the Linux VM that re-assigns
these to the correct values, but since it's been restored from R3.2 it
might not be working. From within vm-work, try assigning the above values
manually. Check another working VM for the appropriate DNS settings.

-- 
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 post to this group, send email to qubes-users@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/qubes-users/6bed5eb824e746a772e3456fb1df5fd9.squirrel%40tt3j2x4k5ycaa5zt.onion.
For more options, visit https://groups.google.com/d/optout.


Re: [qubes-users] Linux VMs can't reach network after restoring from backup to fresh 4.0rc3 install

2018-02-21 Thread ThierryIT
Le mercredi 21 février 2018 12:07:55 UTC+2, ThierryIT a écrit :
> Le mercredi 21 février 2018 11:36:53 UTC+2, awokd a écrit :
> > On Wed, February 21, 2018 9:28 am, ThierryIT wrote:
> > > Le mercredi 21 février 2018 11:13:55 UTC+2, awokd a écrit :
> > 
> > >> OK, then go into Settings on your problem AppVM and change both the
> > >> Template and NetVM to some other value and hit OK. Then, go back into
> > >> Settings and change them back to the values used by your working AppVMs
> > >> and hit OK and try it out.
> > >
> > > Cannot change the template  it is in grey
> > 
> > From your other email and this one, all AppVMs restored from R3.2 have
> > their template setting in grey, even when powered off? What happens if you
> > try to change it from the command line with qvm-prefs?
> 
> qvm-prefs vmname template fedora-26
> 
> vm-prefs: error: no such property: 'template'

the not working VM prefs:

autostart   D  False
backup_timestampU
debug   D  False
default_dispvm  D  fedora-25-dvm
default_userD  user
gateway D  
gateway6D  
include_in_backups  D  True
installed_by_rpmD  False
ip  D  10.137.0.11
ip6 D  
kernel  D  4.14.18-1
kernelopts  D  nopat
klass   D  TemplateVM
label   -  green
mac D  00:16:3E:5E:6C:00
maxmem  D  4000
memory  D  400
name-  vm-work
netvm   -  proxyVM-eth
provides_network-  False
qid -  11
qrexec_timeout  D  60
start_time  D  1519206767.23
stubdom_mem U
stubdom_xid D  18
updateable  D  True
uuid-  5735bd73-e50f-4a63-9a34-6be0b2dc7d3a
vcpus   D  2
virt_mode   -  hvm
visible_gateway D  10.137.0.18
visible_gateway6D  
visible_ip  D  10.137.0.11
visible_ip6 D  
visible_netmask D  255.255.255.255
xid D  17

-- 
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 post to this group, send email to qubes-users@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/qubes-users/9afeb3bb-9e51-49ce-af5c-93f0125ca895%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.


Re: [qubes-users] Linux VMs can't reach network after restoring from backup to fresh 4.0rc3 install

2018-02-21 Thread ThierryIT
Le mercredi 21 février 2018 11:36:53 UTC+2, awokd a écrit :
> On Wed, February 21, 2018 9:28 am, ThierryIT wrote:
> > Le mercredi 21 février 2018 11:13:55 UTC+2, awokd a écrit :
> 
> >> OK, then go into Settings on your problem AppVM and change both the
> >> Template and NetVM to some other value and hit OK. Then, go back into
> >> Settings and change them back to the values used by your working AppVMs
> >> and hit OK and try it out.
> >
> > Cannot change the template  it is in grey
> 
> From your other email and this one, all AppVMs restored from R3.2 have
> their template setting in grey, even when powered off? What happens if you
> try to change it from the command line with qvm-prefs?

qvm-prefs vmname template fedora-26

vm-prefs: error: no such property: '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 post to this group, send email to qubes-users@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/qubes-users/f015c3d7-d4be-438c-9a39-002ef31bea16%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.


Re: [qubes-users] Linux VMs can't reach network after restoring from backup to fresh 4.0rc3 install

2018-02-21 Thread 'awokd' via qubes-users
On Wed, February 21, 2018 9:28 am, ThierryIT wrote:
> Le mercredi 21 février 2018 11:13:55 UTC+2, awokd a écrit :

>> OK, then go into Settings on your problem AppVM and change both the
>> Template and NetVM to some other value and hit OK. Then, go back into
>> Settings and change them back to the values used by your working AppVMs
>> and hit OK and try it out.
>
> Cannot change the template  it is in grey

>From your other email and this one, all AppVMs restored from R3.2 have
their template setting in grey, even when powered off? What happens if you
try to change it from the command line with qvm-prefs?

-- 
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 post to this group, send email to qubes-users@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/qubes-users/f317e1f868cd715e1c9fac96a09dc701.squirrel%40tt3j2x4k5ycaa5zt.onion.
For more options, visit https://groups.google.com/d/optout.


Re: [qubes-users] Linux VMs can't reach network after restoring from backup to fresh 4.0rc3 install

2018-02-21 Thread ThierryIT
Le mercredi 21 février 2018 11:13:55 UTC+2, awokd a écrit :
> On Wed, February 21, 2018 9:07 am, ThierryIT wrote:
> > Le mercredi 21 février 2018 10:58:51 UTC+2, awokd a écrit :
> 
> >> To make sure I understand what you are doing:
> >> You have an AppVM based on a Fedora template backed up from R3.2. You
> >> restored it to R4.0rc4. Other AppVMs restored work fine, except for this
> >>  single AppVM. Correct?
> >
> > yes
> >
> >>
> >> If so, does this problem AppVM use the same template as your working
> >> AppVMs?
> >>
> >
> > yes
> 
> OK, then go into Settings on your problem AppVM and change both the
> Template and NetVM to some other value and hit OK. Then, go back into
> Settings and change them back to the values used by your working AppVMs
> and hit OK and try it out.

Cannot change the template  it is in grey

-- 
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 post to this group, send email to qubes-users@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/qubes-users/42c7ca74-cee9-4413-8277-f4403128a7c7%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.


Re: [qubes-users] Linux VMs can't reach network after restoring from backup to fresh 4.0rc3 install

2018-02-21 Thread ThierryIT
Le mercredi 21 février 2018 11:07:29 UTC+2, ThierryIT a écrit :
> Le mercredi 21 février 2018 10:58:51 UTC+2, awokd a écrit :
> > On Wed, February 21, 2018 8:21 am, ThierryIT wrote:
> > > Hi,
> > >
> > >
> > > After having restored Linux VM from Qubes 3.2, this VM base on fedora
> > > template doesn't reach the network. In the same time, I am now using Qubes
> > > 4rc4, same problem.
> > > I only have this problem with this VM,all other VMs from my 3.2 backup are
> > > working.
> > 
> > To make sure I understand what you are doing:
> > You have an AppVM based on a Fedora template backed up from R3.2. You
> > restored it to R4.0rc4. Other AppVMs restored work fine, except for this
> > single AppVM. Correct?
> 
> yes
> 
> > 
> > If so, does this problem AppVM use the same template as your working
> > AppVMs? 
> 
> yes
> 
> If that's not the case, try changing it to use the same template.
> 
> Will try and let you know
> 
> > Also, is it set to use the same NetVM as your working ones?
> 
> yes

It seems that I am not able to change the template of all my restored VMs, in 
Qubes settings, the template is in grey  Even if the VM is off.

-- 
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 post to this group, send email to qubes-users@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/qubes-users/5933edd6-87ac-477d-8c8c-6fb80cf9ab2c%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.


Re: [qubes-users] HTTP proxy & firewall woes

2018-02-21 Thread 'awokd' via qubes-users
On Tue, February 20, 2018 5:09 pm, Demi M. Obenour wrote:
> I use GMail and Thunderbird for email, and Firefox as my browser.  I do
> email and GitHub from a different domain that is more trusted than others
> (it’s blue).
>
>
> I would love to restrict its networking abilities by using firewall
> rules or a filtering proxy.  Sadly, I have not been able to do that without
> breaking at least GMail.  For firewall rules, the culprit seems to be
> Google’s use of DNS load balancing, but I am not sure what is
> breaking for the filtering proxy.  OCSP stapling?
>
> I would much prefer to be able to restrict network access, but I cannot
> break what needs to work.  Does anyone have suggestions?

Probably OCSP stapling like you said. Some filtering proxies can be
configured to pass through SSL/TLS sessions unmolested, but then they
can't filter them by content. You might also try POP3/SMTP vs. IMAP
although Gmail probably uses the same types of certs for both.

-- 
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 post to this group, send email to qubes-users@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/qubes-users/97cf05a7e9acd06309939ae804d054f6.squirrel%40tt3j2x4k5ycaa5zt.onion.
For more options, visit https://groups.google.com/d/optout.


Re: [qubes-users] Linux VMs can't reach network after restoring from backup to fresh 4.0rc3 install

2018-02-21 Thread ThierryIT
Le mercredi 21 février 2018 10:58:51 UTC+2, awokd a écrit :
> On Wed, February 21, 2018 8:21 am, ThierryIT wrote:
> > Hi,
> >
> >
> > After having restored Linux VM from Qubes 3.2, this VM base on fedora
> > template doesn't reach the network. In the same time, I am now using Qubes
> > 4rc4, same problem.
> > I only have this problem with this VM,all other VMs from my 3.2 backup are
> > working.
> 
> To make sure I understand what you are doing:
> You have an AppVM based on a Fedora template backed up from R3.2. You
> restored it to R4.0rc4. Other AppVMs restored work fine, except for this
> single AppVM. Correct?

yes

> 
> If so, does this problem AppVM use the same template as your working
> AppVMs? 

yes

If that's not the case, try changing it to use the same template.

Will try and let you know

> Also, is it set to use the same NetVM as your working ones?

yes

-- 
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 post to this group, send email to qubes-users@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/qubes-users/f9897f6e-09a0-4aca-9b5c-4439c7166a78%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.


Re: [qubes-users] Re: sys-usb / template install yubikey tools ?

2018-02-21 Thread ThierryIT
Le mercredi 14 février 2018 09:49:37 UTC+2, ThierryIT a écrit :
> Le dimanche 11 février 2018 10:08:52 UTC+2, ThierryIT a écrit :
> > Le samedi 10 février 2018 22:58:15 UTC+2, Alex Dubois a écrit :
> > > > On 10 Feb 2018, at 17:46, ThierryIT  wrote:
> > > > 
> > > > Le samedi 10 février 2018 01:44:36 UTC+2, Alex Dubois a écrit :
> > > >> On Saturday, 3 February 2018 22:42:46 UTC, Alex Dubois  wrote:
> > > >>> On Saturday, 3 February 2018 10:12:25 UTC, ThierryIT  wrote:
> > >  Le vendredi 19 janvier 2018 13:19:29 UTC+2, Alex Dubois a écrit :
> > > >> On Friday, 19 January 2018 05:57:16 UTC, ThierryIT  wrote:
> > > >> Not familiar with this ... Will need procediure to follow.
> > > >> 
> > > >> 
> > > >> Le mercredi 17 janvier 2018 23:03:31 UTC+2, Alex Dubois a écrit :
> > > >>> On Wednesday, 17 January 2018 15:15:45 UTC, ThierryIT  wrote:
> > >  No, I am still under R3.2
> > >  
> > >  Le mercredi 17 janvier 2018 16:54:58 UTC+2, awokd a écrit :
> > > > On Wed, January 17, 2018 2:09 pm, ThierryIT wrote:
> > > >> "https://github.com/adubois/qubes-app-linux-yubikey;
> > > >> 
> > > >> 
> > > >> Le mercredi 17 janvier 2018 16:05:52 UTC+2, awokd a écrit :
> > > >> 
> > > >>> On Wed, January 17, 2018 1:09 pm, ThierryIT wrote:
> > > >>> 
> > >  Nobody ?
> > >  
> > >  
> > >  
> > >  Le mercredi 17 janvier 2018 09:23:34 UTC+2, ThierryIT a 
> > >  écrit :
> > >  
> > >  
> > > > Hi,
> > > > 
> > > > 
> > > > 
> > > > I am going to install a new sys-usb.
> > > > I have before to install all what I need to the template 
> > > > (fedora-26)
> > > > first. When following your procedure:
> > > > 
> > > > 
> > > > ykpers has been installed but: I cannot do the same for
> > > > qubes-yubikey-vm and qubes-yubikey-dom0 :
> > > > 
> > > > no match for argument
> > > > 
> > > > ideas ?
> > > >>> 
> > > >>> Not quite sure what you are trying to do here. What 
> > > >>> procedure? What
> > > >>> command are you entering?
> > > > 
> > > > Are you trying this on Qubes 4.0? Those Yubikey packages might 
> > > > not be in
> > > > the Qubes repo yet.
> > > >>> 
> > > >>> Hi,
> > > >>> 
> > > >>> I have not maintained this for some time. So long that I can't 
> > > >>> remember if the packages had been created/tested, I don't think 
> > > >>> they have.
> > > >>> 
> > > >>> Best is you follow the steps to build it on a new temporary VM, 
> > > >>> don't be afraid it should not be too hard:
> > > >>> - Execute the yum command in "Build dependancies"
> > > >>> - Also install pam-devel
> > > >>> - Follow the steps in preparing the build and build
> > > >>> - Deploy the code in Dom0 and the USB VM.
> > > >>> 
> > > >>> I am about to upgrade to Qubes 4.0 rc4 (when released) so won't 
> > > >>> probably be able to help until this is done.
> > > >>> 
> > > >>> Any help from someone who is used to packaging under Fedora would 
> > > >>> be nice.
> > > >>> 
> > > >>> Alex
> > > > 
> > > > Sure, I'll update the doc and post here. However as I said don't 
> > > > want to touch my Qubes set-up before my upgrade to 4.0 rc4. So 
> > > > might be in 2-3weeks
> > >  
> > >  Did you upgrade to Q4R4 ?
> > > >>> 
> > > >>> I'm in the process. Having issues with PCI path-through of my second 
> > > >>> NIC that I need to solve. I have to use PV mode for now and not too 
> > > >>> happy to have too. I'll open another thread if I can't find a way...
> > > >> 
> > > >> Hi Thierry,
> > > >> 
> > > >> I have recompiled it OK. This was working on R3.2. You can test it on 
> > > >> R4 but no idea if it will work. I hope to have a bit of time to look 
> > > >> at it this week.
> > > >> 
> > > >> To compile it if you want to test / debugInR4
> > > >> create new VM with network (to get the github) or without network but 
> > > >> you'll have to copy the download to the VM by another mean. Then:
> > > >> yum install pam-devel gettext-devel git libtool libyubikey 
> > > >> libyubikey-devel -y
> > > >> yum group install "Development Tools"
> > > >> git clone https://github.com/adubois/qubes-app-linux-yubikey.git
> > > >> cd qubes-app-linux-yubikey/
> > > >> libtoolize --install
> > > >> autoreconf --install
> > > >> ./configure
> > > >> make check
> > > >> 
> > > >> files to copy to Dom0 are in folder back-end
> > > >> files to copy to USBVM are in folder front-end
> > > >> 
> > > >> USBVM should be a VM started on boot with the USB controller that you 
> > > >> insert the key in...
> 

Re: [qubes-users] Linux VMs can't reach network after restoring from backup to fresh 4.0rc3 install

2018-02-21 Thread 'awokd' via qubes-users
On Wed, February 21, 2018 8:21 am, ThierryIT wrote:
> Hi,
>
>
> After having restored Linux VM from Qubes 3.2, this VM base on fedora
> template doesn't reach the network. In the same time, I am now using Qubes
> 4rc4, same problem.
> I only have this problem with this VM,all other VMs from my 3.2 backup are
> working.

To make sure I understand what you are doing:
You have an AppVM based on a Fedora template backed up from R3.2. You
restored it to R4.0rc4. Other AppVMs restored work fine, except for this
single AppVM. Correct?

If so, does this problem AppVM use the same template as your working
AppVMs? If that's not the case, try changing it to use the same template.
Also, is it set to use the same NetVM as your working ones?


-- 
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 post to this group, send email to qubes-users@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/qubes-users/5c15799e7f7a718d433a761acfaf577f.squirrel%40tt3j2x4k5ycaa5zt.onion.
For more options, visit https://groups.google.com/d/optout.


[qubes-users] Can't install Qubes, Rebooting after loading initrd.img

2018-02-21 Thread Daniil .Travnikov
I can't install Qubes Release 4.0-rc4 in some reason.


I use the Rufus tool for “DD image” on 8 GB Flash Drive, after that I see in 
Boot Menu this 2 kind of select:
---
EFI:JetFlashTranscend 8GB 1100HD(Part1,Sig2161DF44)
JetFlashTranscend 8GB 1100
---



When I choose the 1st one with EFI:... it's showing some black screen:
---
Xen 4.8.3 (c/s) EFI loader
Using configuration file 'BOOTX64.cfg'
vmlinuz: 0x8a01f000-0x8a71adb8
initrd.img: 0x88c6f000-0x8a01e64c
---
and after that just rebooting.


But when I choose another JetFlash... it's showing Menu where I can choose 
Install methods. I am choosing Install Qubes R4.0-rc4 and see black screen:
---
Loading xen.gz... ok
Loading vmlinux... ok
Loading initrd.img... ok
---
and after that flickering cursor on whole black sreen and rebooting.


How and what I must fix?

-- 
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 post to this group, send email to qubes-users@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/qubes-users/64809f09-768a-4528-8b0a-17b41a2f3a29%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.


[qubes-users] Linux VMs can't reach network after restoring from backup to fresh 4.0rc3 install

2018-02-21 Thread ThierryIT
Hi,

After having restored Linux VM from Qubes 3.2, this VM base on fedora template 
doesn't reach the network.
In the same time, I am now using Qubes 4rc4, same problem.
I only have this problem with this VM,all other VMs from my 3.2 backup are 
working.

Thx

-- 
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 post to this group, send email to qubes-users@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/qubes-users/2cb51b4e-10a1-4d35-b888-4d5953b347d9%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.


[qubes-users] Re: Playing with docker in an app-vm

2018-02-21 Thread dba972
Le jeudi 24 novembre 2016 14:05:30 UTC+1, Opal Raava a écrit :
> Hi all, 
> 
> I've not seen many docker posts, but for the heck of it I'd like to report on 
> how I made an app-vm that has a website running in docker and reachable by 
> everything connected to sys-firewall.
> 
> 1) install docker in fedora-24, dnf install docker
> 
> 2) create the new appvm, I called it 'docker'
> 
> 3) in that app-vm in /rw/config/rc.local, i put:
> 
> rm -rf /var/lib/docker
> ln -s /home/user/docker /var/lib/docker
> systemctl start docker
> 
> , and I made the dir in /home/user/docker
> now as root i can use 'docker ps' and everything.
> 
> 
> 4) networking, making 'docker' visible:
>on docker app-vm in /rw/config/qubes-firewall-user-script, i put:
> 
> iptables -I INPUT -s 10.137.2.0/24 -j ACCEPT
> 
>on sys-firewall, in /rw/config/qubes-firewall-user-script, i put:
> 
> iptables -I FORWARD 2 -s 10.137.2.0/24 -d $(docker-appvm-ip) -j ACCEPT
> 
> Ok, that's all i have on docker, and it works great.

Hello Opal Raava.

Thanks for this post.
I am newbie in Qubes OS.
I'd like to create an appVM having an HTTPS (Port 443) website running in 
docker.
When i start the docker container i set the following option : -p 2443:443 

But, i failed with configurating sys-firewall, and my browser refuses to access 
to the https website.


Did you met this case ? 

Thanks for you ideas around the sys-firewall/https forward.

Regards

Mac

-- 
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 post to this group, send email to qubes-users@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/qubes-users/fc3afeec-3d49-42c2-bd6e-e2ecd107beac%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.