[qubes-users] Re: Mirage .1 for NetVM?

[Tim W]

On Wednesday, February 1, 2017 at 7:19:28 PM UTC-5, Drew White wrote:
> Hi folks,
> 
> I was always told that mirage would be a good external firewall/netvm for 
> qubes, however I am unable to get it to work for unknown reason.
> 
> Anyone out there been able to get it to work?
> 
> Or does anyone know of another similar item that can be made to be a netvm?
> 
> Sincerely,
> Drew.


Drew,

Did you read thru this thread:  
https://groups.google.com/forum/#!searchin/qubes-users/Unikernels$20and$20Qubes/qubes-users/h03-1hiNMCc/DlWjysajEAAJ

Not sure if the links within are still gtg but I know a number of people per 
the thread got it working.  For me at the very least I think the sys-vms should 
have only what is need in there build for their there function and NOTHING 
more.  Keep it light and the least amount of overhead and code a possible.  UK 
are light and seem to be a good fit.  

For me at the very least linux kernel with only what is needed for that 
specific sys-vm function.  Not exactly sure why it was not done that way from 
the start.  The templates are easy enough such as the minimal ones.

Post up if you get this working and some details.  I would not mind trying it 
out myself for testing.

-- 
You received this message because you are subscribed to the Google Groups 
"qubes-users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to qubes-users+unsubscr...@googlegroups.com.
To 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/8aa44da2-f590-43be-a255-d5df60156aab%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [qubes-users] Archlinux Community Template Qubes OS 3.2

[Tim W]

On Friday, December 30, 2016 at 3:05:55 AM UTC-5, Olivier Médoc wrote:
> On 12/30/2016 03:59 AM, Franz wrote:
> 
> 
> 
>   
> 
> 
> 
> 
> 
>   
> On Thu, Dec 29, 2016 at 2:41 AM,
> Franz <169...@gmail.com>
> wrote:
> 
> 
>   
> 
> 
> 
> 
> 
>   
> On Mon,
>   Dec 19, 2016 at 3:06 PM, J. Eppler 
> 
>   wrote:
> 
>   Hello,
> 
> 
> 
> I just wanted to thank the person who created
> and uploaded the qubes-template-archlinux 3.0.6
> to the Qubes OS 3.2 rpm repo.
> 
> 
> 
> Saved a lot of work.
> 
> 
> 
> You can installed it with:
> 
> sudo qubes-dom0-update
> --enablerepo=qubes-templates-community
> qubes-template-archlinux
> 
> 
> 
> 
> 
>   
>   
> 
> 
>   
> 
> 
> A really nice Christmas present! Thanks
> 
>   
> 
> 
> 
> When I digit 
> 
>    sudo pacman-key -populate archlinux
> 
> 
> 
> I get
> 
> 
> 
> pacman-key: invalid option -- 'p'
> 
>   
> 
> 
>   
> 
>   
> 
> 
> 
> 
> 
> 
> I found the issue, there is a small clerical error in
>   the documentation with a single"-". It should be 
> 
>   sudo pacman-key --populate archlinux
> 
> 
> 
> not
> 
>   sudo pacman-key -populate archlinux 
> 
> 
>   
> 
>   
> 
> 
> 
> By the way, the Qubes Update Proxy Service is now supported and most
> of the pacman configuration occurs in /etc/pacman.d/ files with
> requiring specific changes.
> 
> 
> 
> 
> 
> 
> 
> I will check that based on a new template and fix the documentation
> accordingly.


Oiivier,

Its great pacman is now supported for updating.  When I was working with others 
to update the  build and doc to work with newer archlinux versions I tried most 
everything asking many on the archlinux forum for help.  No one could offer a 
good solution that did not break update security or require manual opening and 
closing of the firewall access.

https://groups.google.com/forum/#!searchin/qubes-users/tim$20w$20pacman/qubes-users/vT_ETcU5BvQ/sDhu879WDQAJ
 I also had a thread on dev.  

How was the functionality added?  To pacman to allow for proxy addition without 
going thru wget or thru a change in qubes update proxy service?  

I found the powerpill pacman wrapper which used aria2 to allow for proxy 
without breaking update proxy security to be at the time the best avenue not to 
mention its added power and speed.  The only issue to have made everything 
completely smooth was the reflector app to keep update mirror list current had 
no option to allow for a proxy entry.  I planned to send a email to xyne to see 
if he could add it as he has been quite responsive in the past to similar 
request.

Really glad its now working.  The reason I ask about how it was addressed is I 
wondered if it would allow reflector program to go thru or does it have still 
have the proxy option to plug in the ip?

Thanks again for keeping the distro updated and working.

-- 
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/d54b2320-db95-4e0a-a7e2-7590691123c9%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[qubes-users] Re: Two ways of "true" security.

[Tim W]

On Thursday, February 2, 2017 at 5:07:08 AM UTC-5, mr@gmail.com wrote:
> This text was written using Google translate.
> As we know, there are two potentially dangerous technology Hardware Trojan: 
> Intel ME and AMD PSP
> I have not seen AMD, so I decided to make the maximum performance and 
> security system based on intel. First, I began to choose the chipset. After 
> reading about the technology intel amt my choice fell on the p965 and n790i. 
> I needed a chipset meets the following conditions:
> 1). No intel amt.
> 2). maximum capacity
> 3) not less than FSB 1333 for the installation of fast xeon
> 4). DDR3
> 
> The chipsets p965 not natively support 1333 FSB CPUs, but there is a 
> development from the company gigabyte allowing the use of this frequency on 
> these chipsets. This is possible on the board (the last revision ONLY):
> GA-965P-DQ6;
> GA-965P-DS4;
> GA-965P-DS3P;
> GA-965P-DS3;
> GA-965P-S3.
> Unfortunately, these boards do not support DDR3.
> 
> But the chipset nForce 790i decide my problems! 1600 MHz FSB, DDR3 2000 MHz! 
> Ideally! Plus, the Intel Xeon E5472 support.
> It seemed, would have found a solution ... But there is no support EPT, and 
> VT-d, required for qubes rel.4.
> 
> Based on the above, there are two ways:
> 1). Use Qubes Release 4.x, and be subject to the influence of Hardware Trojan 
> Intel (AMD?).
> 2). Use Qubes Release 3.x and be subject to the influence of XSA 148 types of 
> errors.
> 
> Which path to choose?

There are bios hardware flash that will disable/uninstall all but 2 packages of 
Intel ME IIRC removing 5 packages.  This is so far the best I have seen for 
getting as close as we can with limiting what amounts to a intel low level OS 
which tech has the power to circumvent anything we do at the user OS level.  No 
longer does the baremetal term apply as it use to in the past.  The CPU and 
chipset manf as wanting and taking more and more control away from the primary 
OS thus locking us down more and more and increasing their control of the 
entire PC.

-- 
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/9532583e-c2ee-4703-8212-b1965c687249%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [qubes-users] Archlinux Community Template Qubes OS 3.2

[Tim W]

On Saturday, December 31, 2016 at 3:00:40 PM UTC-5, hed...@tutanota.com wrote:
> @Olivier Medoc
> 
> 
> First off, thank you for all the work you've clearly put into the Arch Linux 
> build and documentation for Qubes.
> 
> 
> FYI, I'd just like to add my own experiences when I tried to use the new 
> template. (Since I was using the ready-built template, I skipped your build 
> instructions and started at section "Package Manager Proxy Setup Section".):
> 
> 
> 1. After the initial download, the template VM wouldn't close down and was 
> eventually killed by the qubes-dom0-update script. That behaviour was 
> repeated after I started and tried to shutdown the template VM myself.
> 2. Just like Francesco, I had difficulty reading the command lines, because 
> it is virtually impossible to distinguish a single- from a double-dash and 
> copy/paste wasn't working. I tried in both Firefox and Chromium so it wasn't 
> browser related. A fixed-pitch font should do the trick.
> 3. Since gnome-terminal wouldn't open, it would have been useful if you had 
> specifically named the "archlinux terminal app" for those of us not versed in 
> Arch Linux. I used xterm as a fallback, which worked, but later found out 
> that there is an xfce4-terminal that is very like gnome-terminal.
> 4. Step 3 Install Pacman failed with an error about a database file not 
> existing. Some research led me to try "pacman -Syy" (I think without "sudo") 
> which did the trick. 
> 5. Step 7 Configure Powerpill...  the description (though not the example) 
> omits the need for a comma on the preceding line.
> 
> 
> Otherwise, it's now all up and running. Now all I have to do is get my head 
> around Arch!
> 
> 
> Mike

Mike,

The errors in syntax in the instructions are my fault.  I helped update the 
entire instruction guide and obviously there are some typos.   While I did post 
it all up for review those must have slipped thru.  It was alot of new 
instructions and images.  I was trying to make it so people could c the 
various cmds to try and make it that much easier.   The issue being that some 
of them did not obviously transfer correctly and or I typo'd.  Not sure how it 
happened as I took the images and c the cmds as part of a full template build 
which was successful but somehow it seems it did happen.

The reason powerpill was not given specific configs was at the time a number of 
people had posted that pacman should have had a option to config the proxy ip 
which ended up not being the case at least not from anything I could find.  I 
left it up to the end user then to decide as it was not a direct part of 
building the actual archlinux template.

I am happy to add the powerpill config instructions but if you do a basic 
search on its use of aria2 that it uses its straight forward.  Its a basic 
config file with single line item config with very basic syntax.  It would have 
to be for me to get it to work LOL.

The instruction page is 100% editable for change submissions so any errors you 
see you can submit the changes to fix it.  If you prefer list them here giving 
me the step number and the error and I can go back and fix it.

-- 
You received this message because you are subscribed to the Google Groups 
"qubes-users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to qubes-users+unsubscr...@googlegroups.com.
To 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/167cd847-e907-46d1-bff3-f4138099910b%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [qubes-users] Re: Installing using pacman command

[Tim W]

On Thursday, February 2, 2017 at 9:14:45 AM UTC-5, trule...@gmail.com wrote:
> Hi, Tim. Olivier said :
> 
> "Archlinux currently upgraded xorg and pulseaudio, however the integrated 
> archlinux gui agent must be build for strict versions of xorg-server and 
> pulseaudio. For this reason, you have to rebuild the agent using the 
> most recent qubes repository, or wait for binary agents to be available. "
> 
> Powerpill or Pacman, it doesn't matter, update system and break dependency 
> and can't install anything.

Ok I miss understood the issue.   Yes that is the same issue we ran into if you 
do a search on the template a while back.  For that is was pulseaudio.   When 
xorg or pulseaduio versions are updated by ARchlinux we end up having to 
rebuild the template from source.  If not you just get the failed errors when 
trying to update.

The issue I was originally speaking of was not being able to assign pacman a 
proxy ip to use the qubes update proxy.  AT least not without breaking the 
security model for it hence the while powerpill etc comments.  

THere is another thread running concurrently that is dealing with the same 
issue so maybe best to just use that thread to address the issue.

-- 
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/4bc2bfac-00dc-41e9-a032-69d541fd384d%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[qubes-users] Re: Fedora-minimal Based netVM Not Working

[Tim W]

On Sunday, February 5, 2017 at 9:21:05 PM UTC-5, jimmy@gmail.com wrote:
> I have a netVM that works fine with a regular Fedora template but not 
> Fedora-minimal. I've tried both Fedora-23-minimal and Fedora-24-minimal but 
> neither seems work.
> 
> The icon for networking does appear on the panel but Wi-Fi is not on it and 
> there is no option to enable it. So it seems like I'm part-way there but 
> something isn't right when it comes to wireless specifically--though I'm new 
> to both Qubes and Linux, so I could be very wrong about that.
> 
> Taking into account the known issue with installing software in 
> Fedora-24-minimal (GitHub Issue #2606), I've taken care to manually install 
> the recommended packages, specifying version number. I've then verified that 
> the library has no newer version of each package, so I know they are all in 
> place and up to date. Same for 23-minimal.
> 
> Still, neither works thus far.
> 
> Fedora-minimal seems like a nicely economical way to go, so I would really 
> like to get it working. Any and all help would be much appreciated! :-)



It might help if you posted up a list of all the packages you installed tot he 
minimal template for NetVM support.

Here is a list for both FW and Net that Rudd-O posted up in a thread for me 
when I asked what was needed for net and fw temp using Fedora-minimal:

tar
- qubes-tor-repo
- qubes-tor
- dconf
- NetworkManager
- NetworkManager-wifi
- network-manager-applet
- linux-firmware
- dbus-x11
- gnome-keyring
- wireless-tools
- wpa_supplicant
- iwl7260-firmware
- tinyproxy
- which
- pciutils
- usbutils


Vít Šesták mentioned doing a net and fw Fed-min and it worked.  He also 
mentioned installing "haveged" utility program as well.  He stated having issue 
with net-card firmware as it seemed to need different firmware than the full 
version for some reason.  He found it via a complaint in a log.

The thread it was all in I was able to just find again so here is the link:

Unikernels and 
Qubes
 -

Scroll down almost to the end and look for the last time Vít Šesták posted.  
Its one of the last couple posts on 1/4/16.  That is where it starts about the 
fedora minimal between Him myself and  Manuel/Rudd-o.   Maybe that might be of 
some help.

-- 
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/06bae092-1646-4eae-a695-d78706bdafcd%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [qubes-users] Re: How to use a and which mailclient in QUBES (via TOR)?

[Tim W]

On Thursday, February 23, 2017 at 7:59:44 PM UTC-5, Unman wrote:
> On Thu, Feb 23, 2017 at 08:57:23PM -, pixr...@mail2tor.com wrote:
> > Hello,
> > 
> > I tried to install the first parts to get MUTT running, but run into an
> > error when launching the make command at the end of the guide.
> > 
> > > I need to edit: /usr/local/etc/postfix/sender_relay.
> > > your.m...@exmaple.com [mail.example.com]:submission
> > > your.ot...@mail.com [smtp.mail.com]:smtp
> > 
> > I have understand that :smtp and :submission are just placeholders for 
> > ports.
> > As such I have the following entry in my /usr/local/etc/postfix/saslpass:
> > 
> > [smtp.gmail.com]:587  myusern...@gmail.com:MYPASSWORD
> > 
> > Strangely I run into an error at the end of the postfix guide
> > (https://www.qubes-os.org/doc/postfix/):
> > 
> > I have copied and pasted the content for the
> > "usr/local/etc/postfix/Makefile", but when I enter "sudo make" in
> > /usr/local/etc/postfix
> >  I get the following error message:
> > 
> > [user@mail postfix]$ make
> > Makefile:2: *** missing separator.  Stop.
> > 
> > Any idea where to start troubleshooting from this point on?
> > 
> > I'm running all this command in my App-VM, which is based on the fedora-23
> > Template which I have cloned and installed the additional packages as
> > suggested in the >Qubes Postfix docu.
> > 
> > Pixr
> > 
> 
> This generally indicates that you have a syntax error in the Makefile.
> Spaces not tabs would be an obvious error, particularly if you have
> just done a cut and paste job. Try replacing indent spaces with tabs.
> 
> I don't know what the Fedora package is like, but installing postfix
> using a Debian package is absolutely straightforward to get up and
> running.
> 
> Incidentally, mutt itself does have support for pop and imap, and so
> your use case may enable you to use a much more straightforward set up
> than that described in the docs.
> 
> You say you'll be trying it with a googlemail account, and you should be
> able to find MANY guides online to configuring mutt to work with gmail,
> without struggling with postfix and fetchmail. There is a clear one on
> the mutt wiki.)
> 
> unman

I would say if he wants only pop3 then sure using MUTT built in capabilities is 
ok but for IMAP its far from ideal unless using only a very basic setup.

As he mentioned IMAP I thought the full setup gave a more robust setup.  But 
then again no need to make something more complex than you need so

-- 
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/27dcf9a3-4dbc-49d9-8e62-29ada4ac736c%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[qubes-users] Re: How to use a and which mailclient in QUBES (via TOR)?

[Tim W]

On Wednesday, February 22, 2017 at 2:47:16 PM UTC-5, pix...@mail2tor.com wrote:
> Hello group,
> 
> I'm (somewhat proudly) running Qubes OS on my Thinkpad and new to this group.
> Installation was straight foreward, thanks to the excellent documentation.
> I'm currently migrating all my date into Qubes OS to use it as my primary OS.
> 
> Using TOR via the builtin anon-whonix is super easy and I have
> successfully created a new email address via mail2tor.com /
> http://mail2tor2zyjdctd.onion/.
> 
> I would like to use a mailclient with IMAP/SMTP to access my mail2tor
> mailbox. Within the Anon-Whoonix I haven't found a mailclient.
> 
> Question: Which mail client do you suggest to use?
> 
> - Thunderbird
> - Claws
> - ...
> 
> I would like to use GnuPG and maybe S/MIME with my mail2tor-mail-adress
> via Whoonix/TOR, so the mailclient should support this or offer plugings
> to do so.
> Are there any security concerns storing my GnuPG-Keys (for the
> mail2tor-adress) within the Whoonix VM?
> 
> Kind regards
> 
> Pixr

SOemthing you might consider as you are already moving to a new system (Qubes):

I have switched to a cmd line email client (mail user agent)using a MTA MTR.  
There is qubes doc on how to set it up with MUTT, Postfix and fetchmail or what 
ever combo you wish.  When I look at the security risks with emails, going to 
text only client removes 99% and its fast, slick and powerful.  Combine with 
split GPG and it gives a compete package aong with sticking to light powerful 
programs that each is dedicated to one goal (Unix doctrine).  

-- 
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/4afc4bd2-6bcd-4533-accf-d3d88e460ee8%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [qubes-users] Re: How to use a and which mailclient in QUBES (via TOR)?

[Tim W]

On Thursday, February 23, 2017 at 3:57:29 PM UTC-5, pix...@mail2tor.com wrote:
> Hello,
> 
> I tried to install the first parts to get MUTT running, but run into an
> error when launching the make command at the end of the guide.
> 
> > I need to edit: /usr/local/etc/postfix/sender_relay.
> > your.m...@exmaple.com [mail.example.com]:submission
> > your.ot...@mail.com [smtp.mail.com]:smtp
> 
> I have understand that :smtp and :submission are just placeholders for ports.
> As such I have the following entry in my /usr/local/etc/postfix/saslpass:
> 
> [smtp.gmail.com]:587  myusern...@gmail.com:MYPASSWORD
> 
> Strangely I run into an error at the end of the postfix guide
> (https://www.qubes-os.org/doc/postfix/):
> 
> I have copied and pasted the content for the
> "usr/local/etc/postfix/Makefile", but when I enter "sudo make" in
> /usr/local/etc/postfix
>  I get the following error message:
> 
> [user@mail postfix]$ make
> Makefile:2: *** missing separator.  Stop.
> 
> Any idea where to start troubleshooting from this point on?
> 
> I'm running all this command in my App-VM, which is based on the fedora-23
> Template which I have cloned and installed the additional packages as
> suggested in the >Qubes Postfix docu.
> 
> Pixr

Did you get this to work and configured properly?  

  

-- 
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/bbc8ea74-a612-4402-8075-5e8111fd0697%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[qubes-users] Re: Dumping BIOS

[Tim W]

BIOS today especially with all the extra intel coding have balloned into an 
actual full OS between your user installed OS and the bare metal.

As most all the BIOS code is propriety how exactly can anyone on here claim 
there are no hacks or otherwise?

There is a HUGE difference between chain of trust or having to accept having to 
trust hardware and actually trusting it.

I really do not want to spend any real time digging up bios hacks but a google 
search would at least get you the reports of them. 

Just to offer up one take a look at Bruce Schneier's blog as he wrote on this 
topic very briefly here:  
https://www.schneier.com/blog/archives/2015/03/bios_hacking.html

Not to mention today bios can interact remotely with the hardware vs cellular 
radio ethernet etc.. Unless there is a manual switch to separate it like some 
wifi etc have compared to a software on off mode is basically meaningless as 
its open to being modified and you have no way to audit the code even if you 
wanted to. You have no way of knowing there is not a backdoor that allows them 
to be turned on or settings changed.

While I may no be able to control it I would say with the direction BIOS 
software has been going over the last 1o yrs it presents a very real security 
threat.  Anything that is between my installed OS and the bare metal IMO is of 
the most serious of threats as we are extremely limited in protecting ourselves 
from anything below what we install.  The BIOS is a master key to everything 
above it.

-- 
You received this message because you are subscribed to the Google Groups 
"qubes-users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to qubes-users+unsubscr...@googlegroups.com.
To 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/d5e12bdb-6d03-459d-86f6-dfa9a19b156c%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [qubes-users] rc04

[Tim W]

On Tuesday, January 9, 2018 at 1:16:10 AM UTC-5, Sven Semmler wrote:
> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA256
> 
> On 01/09/2018 12:07 AM, Roy Bernat wrote:
> 
> > What about release rc04? it should be release at 8/1 that  was 
> > yesterday .
> 
> Delayed until the devs have a good workaround for SP1/SP2/Spectre.
> 
> /Sven
> -BEGIN PGP SIGNATURE-
> 
> iQIzBAEBCAAdFiEE18ry22WNibwI1qeq2m4We49UH7YFAlpUXggACgkQ2m4We49U
> H7b7cQ/9EC8aSC9vSuTNl0rVHQtK040eZIrg5sKbsXXLjQbOLkwcpXjvWCiukzj1
> hXvUgWvJs2JHTPd9s8Yu/8KlE9Maf+UcbKGvwTPVG6c4tNOHGFLt7C0bRjYVeCp5
> lW7pnb1e4rYX99aoeX5/SdWaScv6XLbx9CnRSazgBIYJ0WqfseUR8tcAE9HqKCau
> aVrBlbSKLMGgWDx3rRGxJaBv6wf70zGi4SPMeCPQOg2vOJIRyDVGDTEz7LDp/NlA
> VfU+xy6q7FlKeKfecftygpgqYmpgI4OOtsRE4OA8KQRAe9RTq+M+2/nebB8/I8tv
> X6kXe23s/BtD8Me958har4Wd0quioRbS/dIyhmgDpCkrrg7Afzwk+AokqBTqyFhs
> u2WZwoZiqRvRhlBqYp8dR076hx9zDNKSijkCcX5hPdLyX5+B39FGRuEJwz0a7G2F
> h3dgxdRDIM/hxf5Sp2Y9E+O0GZaeERWo1fBdjxdbSZV/5CJTTdHBJfMhQ4RUt4sv
> 2v7/hlgFAhgSvzfXRxemH8elPERHISQ9j3nlKMsa73pnYWpUqeALVfOINbZE8DrU
> 54j5NPZOdhSrDaTtoS8hm2bF4+KFFjAw19B8s/HvHlwZ9B5PgFwV3et7fYYDjGrS
> k0o3nVqKmsooD+yeR+oU/32qz4E0sOq0AxAS1PplU5Y3aMNiZBY=
> =59oT
> -END PGP SIGNATURE-

Great time to be using a AMD chipset as they are not effected.Wonder if 
something like this would have been caught years ago if the microcode was open?

This is a big one in terms of the effects it has when mitigated at the software 
level.  I wonder what the performance hit will be from application of whatever 
patch route Qubes takes?  Projections of 5-30% hit.

As I said Great day for AMD stock LOL

-- 
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/cbbf5444-be4a-4f76-b313-8218b6bd765b%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[qubes-users] Re: Lenovo ThinkPad, won't boot

[Tim W]

On Monday, January 15, 2018 at 6:23:55 PM UTC-5, demio...@gmail.com wrote:
> My Lenovo ThinkPad fails to boot after installing Qubes.  I had to boot the 
> USB drive via legacy boot for Qubes to install at all, but the EFI setup 
> doesn't happen.


need a model number and spec.  should not need legacy mode if hardware/cpu 
matches tp qubes oversion 3 vs 4s 

-- 
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/f03d3112-29ba-4d1c-a421-98a821893b8c%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [qubes-users] How to play videos in qubes? says needs codec H.264, Mpeg-4 something

[Tim W]

On Tuesday, January 16, 2018 at 2:53:54 PM UTC-5, [799] wrote:
> Hello Jerry, 
> 
> What are you trying to accomplish? 
> I have a complete How-to which you can just follow per copy & paste to get a 
> multimedia AppVM which is based on Debian-8 and can be used to listen to 
> Spotify, watch DVD and use Amazon Prime or Spotify.
> If you are interested I can send you the installation script.
> 
> [799]

why not post up the how to as I think many would find it beneficial with so 
many new users.

-- 
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/19abb006-4b28-4003-8d0c-62826a776427%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [qubes-users] rc04

[Tim W]

On Tuesday, January 9, 2018 at 2:35:28 PM UTC-5, Chris Laprise wrote:
> On 01/09/2018 05:17 AM, Roy Bernat wrote:
> > On Tuesday, 9 January 2018 11:12:17 UTC+2, msg...@gmail.com  wrote:
> >> On Tuesday, January 9, 2018 at 2:11:06 PM UTC+7, Tim W wrote:
> >>> On Tuesday, January 9, 2018 at 1:16:10 AM UTC-5, Sven Semmler wrote:
> >>>> -BEGIN PGP SIGNED MESSAGE-
> >>>> Hash: SHA256
> >>>>
> >>>> On 01/09/2018 12:07 AM, Roy Bernat wrote:
> >>>>
> >>>>> What about release rc04? it should be release at 8/1 that  was
> >>>>> yesterday .
> >>>>
> >>>> Delayed until the devs have a good workaround for SP1/SP2/Spectre.
> >>>>
> >>>> /Sven
> >>>> -BEGIN PGP SIGNATURE-
> >>>>
> >>>> iQIzBAEBCAAdFiEE18ry22WNibwI1qeq2m4We49UH7YFAlpUXggACgkQ2m4We49U
> >>>> H7b7cQ/9EC8aSC9vSuTNl0rVHQtK040eZIrg5sKbsXXLjQbOLkwcpXjvWCiukzj1
> >>>> hXvUgWvJs2JHTPd9s8Yu/8KlE9Maf+UcbKGvwTPVG6c4tNOHGFLt7C0bRjYVeCp5
> >>>> lW7pnb1e4rYX99aoeX5/SdWaScv6XLbx9CnRSazgBIYJ0WqfseUR8tcAE9HqKCau
> >>>> aVrBlbSKLMGgWDx3rRGxJaBv6wf70zGi4SPMeCPQOg2vOJIRyDVGDTEz7LDp/NlA
> >>>> VfU+xy6q7FlKeKfecftygpgqYmpgI4OOtsRE4OA8KQRAe9RTq+M+2/nebB8/I8tv
> >>>> X6kXe23s/BtD8Me958har4Wd0quioRbS/dIyhmgDpCkrrg7Afzwk+AokqBTqyFhs
> >>>> u2WZwoZiqRvRhlBqYp8dR076hx9zDNKSijkCcX5hPdLyX5+B39FGRuEJwz0a7G2F
> >>>> h3dgxdRDIM/hxf5Sp2Y9E+O0GZaeERWo1fBdjxdbSZV/5CJTTdHBJfMhQ4RUt4sv
> >>>> 2v7/hlgFAhgSvzfXRxemH8elPERHISQ9j3nlKMsa73pnYWpUqeALVfOINbZE8DrU
> >>>> 54j5NPZOdhSrDaTtoS8hm2bF4+KFFjAw19B8s/HvHlwZ9B5PgFwV3et7fYYDjGrS
> >>>> k0o3nVqKmsooD+yeR+oU/32qz4E0sOq0AxAS1PplU5Y3aMNiZBY=
> >>>> =59oT
> >>>> -END PGP SIGNATURE-
> >>>
> >>> Great time to be using a AMD chipset as they are not effected.Wonder 
> >>> if something like this would have been caught years ago if the microcode 
> >>> was open?
> >>>
> >>> This is a big one in terms of the effects it has when mitigated at the 
> >>> software level.  I wonder what the performance hit will be from 
> >>> application of whatever patch route Qubes takes?  Projections of 5-30% 
> >>> hit.
> >>>
> >>> As I said Great day for AMD stock LOL
> >>
> >> AMD is affected by the SP1/SP2/Spectre as well as Intel and ARM.
> > 
> > So he can not dance :)
> > 
> 
>  From my recollection of AMD statements:
> 
> SP1: Very hard to exploit on any CPU
> 
> SP2: Much harder to exploit on AMD than Intel
> 
> SP3/Meltdown: AMD not affected
> 
> -- 
> 
> Chris Laprise, tas...@posteo.net
> https://github.com/tasket
> https://twitter.com/ttaskett
> PGP: BEE2 20C5 356E 764A 73EB  4AB3 1DC4 D106 F07F 1886

that sounds correct based on what I have read.  At first AMD claimed it was not 
effected but it seems as time went on and it was looked at more carefully that 
has changed.  Still I will take more difficult.  As AMD has such a small share 
of processor space it makes it a lower target sort of how Apple use to be to 
windows and linux still is although not like it use to be.  So really with a 
qubes WS the main issue would be SP2 mitigation.

Amazing this has been an issue for 10yrs.  
 

-- 
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/5d30b510-7df0-44cc-8930-adb1883cc208%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[qubes-users] Re: Lenovo ThinkPad, won't boot

[Tim W]

Here is a thread with steps to get uefi install of 3.2 working on the p51 from 
a few weeks ago

https://groups.google.com/forum/m/#!topic/qubes-users/4VsKdxnKHBk

Cbeers,

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/2040e8e3-e440-4df4-9098-fa7d9376a7a8%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[qubes-users] Qubes installed and booted correctly. But password does not work.

[Tim W]

Wbat version of qubes 3.2 or 4.0?

So its the scrn lck password the first luks password is fine.   I thought this 
was fix3d but I have not changed mine is so long as i did it manuallyqubes 
when you cirst install have to use the username user for the first time during 
setup.  After that you can create a different username password combo.  Again 
this is if this was not changed in updates.  I just got use to usimg uswrname 
user duri g install setup and chnaging later so I wohld not have noticed it 
being fixed.  

I defer to anyone that is more current on this but I would redo setup and make 
username user and set the password.  Then after that add a different username 
password or just keep user as name whatever.  AgaiN I difer to other that are 
more current on this.

-- 
You received this message because you are subscribed to the Google Groups 
"qubes-users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to qubes-users+unsubscr...@googlegroups.com.
To 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/54f09f0b-d61b-4cac-af4e-f1938b5ce284%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[qubes-users] Re: Qubes 4.0 / Qubes in general

[Tim W]

On Monday, February 5, 2018 at 4:37:26 AM UTC-5, rob_66 wrote:
> On Sun, 4 Feb 2018 12:17:41 -0800 (PST)
> Yuraeitha  wrote:
> 
> > I think discussion is good and healthy, though I don't feel it's entirely 
> > fair to paint it black
> > and white like this. I can agree on many problems, but I think they look 
> > very different in
> > different light and perspectives, so lets try shake it up a bit. I'm not 
> > claiming to be right,
> > this is just my perspective of things. 
> > 
> > The ancient city Rom wasn't build in one day, it took many decades and even 
> > centuries. And as
> > awokd said, the security in Qubes is rapidly evolving in short time, which 
> > is hard to deny. Qubes
> > is heavily disrupting the security industry, which has been too stagnant 
> > and slowly reactive
> > developing over many years, rather than a proactive forward looking 
> > perspective, which Qubes has. 
> > 
> > The priority is first and foremost security, right? Everything else besides 
> > that is pretty much
> > secondary or lower. Ease of use and emotional related things, such as good 
> > looking and appeal,
> > will come even lower than secondary (don't get me wrong though, I do love 
> > good looking systems
> > too my self). 
> > 
> > While the Qubes OS team could need more funding and donations, I don't 
> > think they are feeling
> > ready yet to go and market themselves before the security is on an even 
> > higher level. And this I
> > think is very justified in a logical sense seen from an understanding of 
> > market perspective, once
> > you start market it, if the security isn't good enough, then Qubes will 
> > just become a short-lived
> > fire-fly that only lives 24 hours, before everyone forgets about it again. 
> > For proper marketing,
> > you need to be ready before spreading the hype. This is why many open 
> > source projects dye out
> > too, they don't live long enough to be ready to deliver, or they deliver 
> > too early or too late.
> > As I see it, the Qubes developers are currently doing a good job enduring. 
> > Security is also the
> > main target group to begin with too, so I feel it's overall very justified 
> > to focus all their
> > energy on security and secondary ease-of-use problems, important mainstream 
> > hardware support, and
> > so on.
> > 
> > We're in early times, and as I see it, currently the fundamentals are being 
> > build in Qubes. The
> > structure which everything else ontop will be changed in the future. I 
> > think it's very wrong to
> > look at Qubes 4 as how Qubes will look like in the future. This is a deep 
> > mistake from other
> > Linux OS's which are very conservative, unchanging, and by all means have 
> > an ingrained reactive
> > thinking pattern, rather than proactively thinking pattern. I think the 
> > Qubes developers have a
> > good forward looking foresight, and this is part of the reason why I like 
> > it so much. But for
> > this reason too, Qubes is often misunderstood if they do things in Qubes 4, 
> > which may first show
> > its full potential in Qubes 5 or Qubes 6.
> > 
> > There is also the question of how much of this is upstream issues? Not 
> > everything is Qubes to
> > fix, and it certainly would be ill advized to start doing what for example 
> > Red Hat is doing and
> > change the code, which has to be done everytime a new update arrives from 
> > upstream. Although I
> > have to admit I have little understanding of codes. 
> > 
> > Also currently we're still seeing rapid development of security in Qubes, 
> > and it's still going.
> > The primary developers of Qubes are busy, so I don't think it's justified 
> > to say any should shift
> > focus to fix lower priority nice looks and appeals, like icons (although I 
> > do enjoy good looking
> > systems, but it's too soon as there are other things to be done in Qubes 
> > first). Why are other
> > developers from the outside not helping with this? The Qubes developers are 
> > busy enough with the
> > security aspect as it is after all. Also if more people helped, and more 
> > put up donations
> > (avoiding too early wide-spread hype though, there is a good timing for 
> > everything), then perhaps
> > we can get issues fixed like missing icons, and so earlier than otherwise.
> > 
> > Which programs and apps can't you run in Qubes? I mean, I can even run 
> > Android with Android
> > apps, it's pretty amazing. What sort of programs do you have that can't run 
> > that well on Qubes?
> > Maybe it can be fixed? 
> > 
> > Lets not forget, Qubes 4 was about future-proofing Qubes. Currently many 
> > things need to be
> > fixed again after having ripped everything apart and putting it together 
> > with many new parts and
> > design shape. Qubes 4 is in many ways, in my understanding, really about 
> > making the upcoming
> > Qubes 5 and onward possible, which is to say, Qubes 4 may not seem so 
> > special, but I'm sure it
> > will start to show and build up 

Re: [qubes-users] Building Qubes 4rc4 iso from source

[Tim W]

On Sunday, February 4, 2018 at 12:55:10 AM UTC-5, Tim W wrote:
> On Sunday, February 4, 2018 at 12:25:46 AM UTC-5, awokd wrote:
> > On Sun, February 4, 2018 4:48 am, Tim W wrote:
> > > On Saturday, February 3, 2018 at 11:39:09 PM UTC-5, awokd wrote:
> > >
> > >> On Sun, February 4, 2018 4:21 am, Tim W wrote:
> > >>
> > >>
> > >>> packages'. Error: Error downloading packages: Status code: 503 for
> > >>> https://mirrors.fedoraproject.org/metalink?repo=fedora-25=x86_64
> > >>>
> > >>
> > >>>
> > >>> An issue with the link in the makefile?
> > >>>
> > >>
> > >> Probably a Fedora repo issue, maybe it's being updated. You might run
> > >> into a bunch of those. All you can do is run "make qubes" again and
> > >> cross your fingers.
> > >
> > > Well that royally sucks.  Its not as if the build process is only 5-10
> > > mins.  That was 30-45 mins to hit that error.
> > >
> > > looked at the makefile.fedora and it looks like this section.  Does it
> > > look correct  I was wondering if something might change with depeciation
> > > of f25
> > 
> > I know, it takes me around 6 hours for a fresh download and full build.
> > Another thing you can try if you're frequently getting download issues
> > (status code 503 is server issue, not missing file) is to build one group
> > of components at a time instead of the full list (which "make qubes"
> > does).
> > If you want to try that instead, do "make help" and look for the list of
> > components towards the end. It's like 10 lines long. Then start copying
> > and pasting them into make, one batch at a time, like "make vmm-xen
> > core-libvirt core-vchan-xen" for the first batch. That way if it fails you
> > don't have to go so far back. Make sure to run them in order.
> 
> great idea.  I had done that on templates when working out issues back before 
> we all got archlinux building well.  Did not think of if for this.  So far 
> this time its still running on the build so hopefully in a few hours I will 
> have an iso.  We will see.  
> 
> After that I think I will start adding in other templates to make a list of 
> what works.   As I can leave it to do its thing will not be a big waste of 
> time.  I am thinking minimal templates should also work.  Then its onto 
> Centos.  I prefer it leaps and bounds over Fedora.  IMO its the ideal dom0 if 
> we need to stick to rpm based with its long LTS.  Now with the longer linux 
> kernel support it will go great together for a long term stable system 
> without having to upgrade.

OK I was able to get a standard build done to iso.  That is standard FC26 + 
Strech-Debain + Whonix.

I also successful built standard + minimal of those to iso as well.  

Next I will try adding in certain other templates 1 by 1.

A correction on the instructions to build these 4.0 ISOs:

You need significantly more private store drive space in the VM.  I am using a 
stand-alone VM FC23 so I have more initial space taken up.  Still with an app 
vm its 2x what the old docs recommend as a minimum.   

For just the standard build I needed 60gigbyes.  

For the standard + minimal 65 gig just barely made it.  Best to have 70 gigs.  

My guess if you wanted to build all the non EOL templates for 4.0rc4 if they 
all can be built would be 100 gigs.  

I will continue to see what will build and the space needed.  My guess is some 
laptops especially that are running ssd will not have the drive space to build 
depending on what's used up already for your system data.  Looks like I finally 
have to add the 1tb Samsung Pro SED SSD in the optical bay for vm user data.  

Still not sure what program differences between the full-loaded-template vs 
Standard-templates.  For me I would rather manually add the programs I wanted 
in each area.  I may try the builds for those so we know if the build or not.

I may also try the last template version to be EOL'd such as fc25 for fedora 
etc but that will be last.  Too bad I do not have quad xeons 1000 +gigs of ram 
workstations vs the T440 with I7 + 16gig.  I could get these built in 15-30 min 
rather than 3 hrs.  

In the attachment is the QM showing Build-Qubes VM Size used for at the end of 
#make iso with FC26-Standard+FC26-Minimal & Stretch-Standard + Stretch-Minimal 
+ Whonix 64309MB


Cheers,

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/32e8fc28-50b9-403e-bead-570445798cef%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[qubes-users] Re: Please help with custom template build

[Tim W]

On Friday, February 2, 2018 at 7:42:26 AM UTC-5, Krišjānis Gross wrote:
> On Tuesday, 23 January 2018 17:36:00 UTC, Krišjānis Gross  wrote:
> > Hi, 
> > 
> > I am trying to build a custom installation .iso. I have an issue that I 
> > have purchased a new set of hardware that does not work with the current 
> > builds of qubes. I am trying to build the most updated version with hope 
> > that it could work. 
> > 
> > I am running a Fedora linux and trying to build with these instructions: 
> > https://www.qubes-os.org/doc/building-archlinux-template/
> > 
> > I use the ./setup to create the installation configuration. 
> > 
> > make install-deps goes fine.
> > make get-sources goes smooth as well
> > 
> > but I get an error when running the mage qubes command.
> > Here is what I get:
> > 
> > [krish@localhost qubes-builder]$ make qubes
> > Currently installed dependencies:
> > git-2.14.3-2.fc27.x86_64
> > rpmdevtools-8.10-3.fc27.noarch
> > rpm-build-4.14.0-2.fc27.x86_64
> > createrepo-0.10.3-12.fc27.noarch
> > debootstrap-1.0.92-1.fc27.noarch
> > dpkg-dev-1.18.24-3.fc27.noarch
> > python2-sh-1.12.14-2.fc27.noarch
> > dialog-1.3-10.20170509.fc27.x86_64
> > dpkg-dev-1.18.24-3.fc27.noarch
> > debootstrap-1.0.92-1.fc27.noarch
> > PyYAML-3.12-5.fc27.x86_64
> > make[1]: Entering directory '/home/krish/qubes-builder'
> > -> Preparing fc25 build environment
> > -> Initializing RPM database...
> > -> Retreiving core RPM packages...
> > -> Verifying signatures...
> > Filename: 
> > /home/krish/qubes-builder/cache/fc25/base_rpms/acl-2.2.52-13.fc25.x86_64.rpm
> >  is not signed.  Exiting!
> > make[1]: *** 
> > [/home/krish/qubes-builder/qubes-src/builder-fedora/Makefile.fedora:86: 
> > /home/krish/qubes-builder/chroot-fc25/home/user/.prepared_base] Error 1
> > make[1]: Leaving directory '/home/krish/qubes-builder'
> > make: *** [Makefile:224: vmm-xen-dom0] Error 1
> > 
> > 
> > Does anyone has an idea of what I do wrong or how to resolve this? 
> > I have attached the builder.conf file that I have.
> 
> Tried to build on Fedora 25 but did not succeed. Did not get the same issue 
> but there was something else that did not work. 
> Kind of gave up trying because of Qubes 4 RC4 release. 
> thank You to everyone for the help!


Could you type out each command you do as well as your choices inside the setup 
script.

I had issues with this and then with a few recommendation by Awokd I have built 
a standard 4.0rd4 and one with both minimal settups without errors.  But you 
have to do each thing in specific order.

I would recommend deleting the qubes-builder directory and start fresh.

Got make sure you get the gpp sig and set the trust properly and move them into 
the qubes-builder directory properly as well.

I am currently trying to go thru the various choices of templates to see what 
works and what fails.  Right now I have added Centos standard into this build.

Make sure you have plenty of HD space as it can take over 60 gigs for even a 
basic build

-- 
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/28a01237-110d-4a5e-8c11-0d954a5420e7%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [qubes-users] Re: Building Qubes 4rc4 iso from source

[Tim W]

On Sunday, February 4, 2018 at 8:51:45 PM UTC-5, Unman wrote:
> On Mon, Feb 05, 2018 at 01:44:10AM +, Unman wrote:
> > On Sat, Feb 03, 2018 at 06:52:12PM -0800, Tim W wrote:
> > > Also when I ran setup script it required PyYaml and that was also shown 
> > > in https://www.qubes-os.org/doc/qubes-builder/ Building Qubes From 
> > > Scratch 
> > > 
> > > Then you have the build directions that there is notes to follow the 
> > > Archlinux directions for using the builder tools and they do not have 
> > > them but then it includes python.sh rather than python2.sh .  The latter 
> > > is definitely needed.
> > > 
> > > Then finally in the README.md file in the qubes-builder which you are 
> > > directed to read it has you install perl-open but not dpkg-dev 
> > > debootstrap and a few others.  So we are basically given directions to go 
> > > to at least 3 different places that all have from slightly different to 
> > > completely different instructions for building qubes.
> > > 
> > > IMHO for the advanced user who wants to build qubes from source the 
> > > ./setup script is by far the easiest to follow as it being a all 
> > > inclusive script handles many steps for you in a nice basic gui.  Issue 
> > > is we need to have some very basic steps of what will work with each OS 
> > > version.  It would only take 10-15 min to update a markup page for each 
> > > os.  Everything is there except what works with what OS and frankly 
> > > that's all in terms of instructions that should have to change ever in 
> > > qubes current xen based format.  If a dev could even just post a list of 
> > > what templates work with the version in the group I or others can easily 
> > > update the doc page.  I have helped in that area before as its one area 
> > > IMO any and all qubes users can help out with and give back to the 
> > > project. 
> > > 
> > 
> > afaik the current instructions on the website are targeted to Fedora 26,
> > the currently supported version, and should be complete.
> > The archlinux instructions are quite out of date and the README definitely
> > needs to be updated.
> > I'm not sure what you mean by OS version, or most of your last
> > paragraph. Can you clarify?
> 
> Sorry, I've gone back to your original post and it's clearer.
> You should be able to build all the templates referenced in the setup
> program. If you can't, then (barring network problems) it's a bug.
> Its a moot point whether you should be building some of the older,
> eol templates, and whether they should be available to build.

Correct on the older templates.  The oldest I would consider is fc25 and wheezy 
etc..   for it to be working correctly without bug I would expect to be able to 
choose all none EOL templates together and have it build.  Would need 100+ gigs 
but it  should work.   That is what I am working towards.

My original issue with setup script might have been part network and part gpg 
sig issue.   Just would like to know and then update the offical Doc etc pages 
with correct info where needed.

The issue with archlinux is it is referenced at least twice in other docs as to 
being the most uptodate instructions for building qubes and templates.  
Basically much of the docs are a mess as they have conflicting missing dif info.

-- 
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/234ee664-b03f-4df9-bff6-628fb956efb8%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [qubes-users] Re: Building Qubes 4rc4 iso from source

[Tim W]

On Sunday, February 4, 2018 at 8:51:45 PM UTC-5, Unman wrote:
> On Mon, Feb 05, 2018 at 01:44:10AM +, Unman wrote:
> > On Sat, Feb 03, 2018 at 06:52:12PM -0800, Tim W wrote:
> > > Also when I ran setup script it required PyYaml and that was also shown 
> > > in https://www.qubes-os.org/doc/qubes-builder/ Building Qubes From 
> > > Scratch 
> > > 
> > > Then you have the build directions that there is notes to follow the 
> > > Archlinux directions for using the builder tools and they do not have 
> > > them but then it includes python.sh rather than python2.sh .  The latter 
> > > is definitely needed.
> > > 
> > > Then finally in the README.md file in the qubes-builder which you are 
> > > directed to read it has you install perl-open but not dpkg-dev 
> > > debootstrap and a few others.  So we are basically given directions to go 
> > > to at least 3 different places that all have from slightly different to 
> > > completely different instructions for building qubes.
> > > 
> > > IMHO for the advanced user who wants to build qubes from source the 
> > > ./setup script is by far the easiest to follow as it being a all 
> > > inclusive script handles many steps for you in a nice basic gui.  Issue 
> > > is we need to have some very basic steps of what will work with each OS 
> > > version.  It would only take 10-15 min to update a markup page for each 
> > > os.  Everything is there except what works with what OS and frankly 
> > > that's all in terms of instructions that should have to change ever in 
> > > qubes current xen based format.  If a dev could even just post a list of 
> > > what templates work with the version in the group I or others can easily 
> > > update the doc page.  I have helped in that area before as its one area 
> > > IMO any and all qubes users can help out with and give back to the 
> > > project. 
> > > 
> > 
> > afaik the current instructions on the website are targeted to Fedora 26,
> > the currently supported version, and should be complete.
> > The archlinux instructions are quite out of date and the README definitely
> > needs to be updated.
> > I'm not sure what you mean by OS version, or most of your last
> > paragraph. Can you clarify?
> 
> Sorry, I've gone back to your original post and it's clearer.
> You should be able to build all the templates referenced in the setup
> program. If you can't, then (barring network problems) it's a bug.
> Its a moot point whether you should be building some of the older,
> eol templates, and whether they should be available to build.

I just added Centos 7 Standard template with the ones that had already built 
correct and as before it errored out with the following:
---
Building core-admin-client (rpm_spec/qubes-core-admin-client.spec) for centos7 
vm (logfile: build-logs/core-admin-client-vm-centos7.log)
--> build failed!
reading sources... [ 92%] manpages/qvm-tags
reading sources... [ 96%] manpages/qvm-unpause
reading sources... [100%] manpages/qvm-volume

/home/user/qubes-src/core-admin-client/doc/manpages/qvm-features.rst:91: ERROR: 
Unknown interpreted text role "py:pbj".
/home/user/qubes-src/core-admin-client/doc/manpages/qvm-firewall.rst:73: 
WARNING: Bullet list ends without a blank line; unexpected unindent.
looking for now-outdated files... none found
pickling environment... done
checking consistency... 
/home/user/qubes-src/core-admin-client/doc/manpages/index.rst:: WARNING: 
document isn't included in any toctree
done
writing... qvm-backup-restore.1 { } Checking arguments for 'qvm-backup-restore'

Exception occurred:
  File "/usr/lib64/python2.7/importlib/__init__.py", line 37, in import_module
__import__(name)
  File 
"/home/user/qubes-src/core-admin-client/qubesadmin/tools/qvm_backup_restore.py",
 line 4
SyntaxError: Non-ASCII character '\xc3' in file 
/home/user/qubes-src/core-admin-client/qubesadmin/tools/qvm_backup_restore.py 
on line 4, but no encoding declared; see 
http://www.python.org/peps/pep-0263.html for details
The full traceback has been saved in /tmp/sphinx-err-JOw4sG.log, if you want to 
report the issue to the developers.
Please also report this if it was a user error, so that a better error message 
can be provided next time.
Either send bugs to the mailing list at 
<http://groups.google.com/group/sphinx-dev/>,
or report them in the tracker at 
<http://bitbucket.org/birkenfeld/sphinx/issues/>. Thanks!
make: *** [man] Error 1
make: Leaving directory `/home/user/qubes-src/core-admin-client/doc'
error: Bad exit status from /var/tmp/rpm-tmp.Hd675A (%build)
---


Any ideas?

--

[qubes-users] Re: Qubes Manager / Qubes 4.0 R3 ?

[Tim W]

This is not directed toward anyone that has posted as I think all have in some 
fashion; be it coding or updating docs something, support.  I know Tom, Awokd 
and Unman have.

To me the only ones I feel have a right to comment on this specific topics are 
people that have at least contributed to the project.   I am not saying I am 
correct but after 25 yrs of open source I have found there way to large a 
percentage of people wanting to be spoon fed and want and want and want.  
Entitlement mentality  without offering anything constructive to the group 
collective projects.

IMO that is the largest issue Qubes struggles with as an opensource project.  
As do many projects.  It seems plenty of people want this or that even demand 
it but rarely are any of them willing or even capable of contributing.  Of 
course all projects needed basic users but this project really really needs 
more devs.

People complain about doc being outdated..then fix them.  If a person is 
capable of loading Qubes OS they sure as hell are capable of creating or 
updating some Markdown pages even if it more cumbersome than a typical document 
format.  A 3rd grader could do it.

With all the users commenting in the qubes-user list there is zero reason Docs 
should ever be outdated for more than a week or two in any area. I have redone 
and created a number of doc pages and a VERY minor amount of updating a couple 
script and conf files. (not much of a coder)  But there is no reason there are 
not 20-30 people that over time should be keeping these docs up to date.

Tom has built a Qubes Controller (manager) based on the 4.0 code and went so 
far as to add in library package so other coding can be used to build.  He has 
been super open to adding functions based on comments.   If another person or 
two could help him with coding now that its not needed to just be python it 
could become the defacto Qubes GUI to manage the qubes system.  That would take 
it off the plate of the core system devs.  i plan to use his controller and if 
the QM does not work well I will stay with his controller.

You have to consider the finances of the core qube dev that are paid. This was 
a huge project moving Qubes forward.  Consider Qubes 1 and how rough it was.  
Look at where we are at now.  Its a long ways.  3.2 was 3 full major revisions 
and many sub revisions of the same basic code where 4.0 is very different 
compared to the other progressive steps of this Os before.  3.1 and finally 3.2 
was getting very polished and it can be a bit of a shock when you have to take 
a step back in polish with such a over all change.  Its going to take time but 
the bugs will be fixed and things will be polished.  

I am not a coder so I will make not comments about python use etc other than it 
seems the reasons were memory-safety vs other.  I tend to wonder if KDE issue 
seen are because they moved officially to XFCE.  I think this may have been 
because of prefer of dev as users and also the low resources of devs to code.  
But as I said I do not have the knowledge to really speak on the topic beyond 
what I have seen.

-- 
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/65a6a008-e562-4b34-89f5-ca0049fe526b%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[qubes-users] Re: qvm-usb is broken in Qubes 4.0 rc4

[Tim W]

On Sunday, February 4, 2018 at 8:50:12 PM UTC-5, Fabrizio Romano Genovese wrote:
> Hello all, 
> 
> When I try to attach my webcam to any appvm, I get the following message:
> 
> Device attach failed: /usr/lib/qubes/usb-import: line 32: 
> /sys/devices/platform/vhci_hcd/status: No such file or directoryNo unused 
> port found!/usr/lib/qubes/usb-import: line 51: 
> /sys/devices/platform/vhci_hcd/attach: No such file or directory
> 
> In the meantime, the devices widget thinks that everything is ok.
> I was able to reproduce this error on two different machines, one upgraded 
> from Qubes 4.0 rc3 and another coming from a fresh install. What should I do?
> 
> Cheers,
> Fab

Open a issue in qubes qit or mention it over on the qubes-devel list.

-- 
You received this message because you are subscribed to the Google Groups 
"qubes-users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to qubes-users+unsubscr...@googlegroups.com.
To 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/72ac85ca-ccf5-43c6-94f2-5d55876a9344%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [qubes-users] Re: Building Qubes 4rc4 iso from source

[Tim W]

On Sunday, February 4, 2018 at 10:42:05 PM UTC-5, Tim W wrote:
> On Sunday, February 4, 2018 at 8:51:45 PM UTC-5, Unman wrote:
> > On Mon, Feb 05, 2018 at 01:44:10AM +, Unman wrote:
> > > On Sat, Feb 03, 2018 at 06:52:12PM -0800, Tim W wrote:
> > > > Also when I ran setup script it required PyYaml and that was also shown 
> > > > in https://www.qubes-os.org/doc/qubes-builder/ Building Qubes From 
> > > > Scratch 
> > > > 
> > > > Then you have the build directions that there is notes to follow the 
> > > > Archlinux directions for using the builder tools and they do not have 
> > > > them but then it includes python.sh rather than python2.sh .  The 
> > > > latter is definitely needed.
> > > > 
> > > > Then finally in the README.md file in the qubes-builder which you are 
> > > > directed to read it has you install perl-open but not dpkg-dev 
> > > > debootstrap and a few others.  So we are basically given directions to 
> > > > go to at least 3 different places that all have from slightly different 
> > > > to completely different instructions for building qubes.
> > > > 
> > > > IMHO for the advanced user who wants to build qubes from source the 
> > > > ./setup script is by far the easiest to follow as it being a all 
> > > > inclusive script handles many steps for you in a nice basic gui.  Issue 
> > > > is we need to have some very basic steps of what will work with each OS 
> > > > version.  It would only take 10-15 min to update a markup page for each 
> > > > os.  Everything is there except what works with what OS and frankly 
> > > > that's all in terms of instructions that should have to change ever in 
> > > > qubes current xen based format.  If a dev could even just post a list 
> > > > of what templates work with the version in the group I or others can 
> > > > easily update the doc page.  I have helped in that area before as its 
> > > > one area IMO any and all qubes users can help out with and give back to 
> > > > the project. 
> > > > 
> > > 
> > > afaik the current instructions on the website are targeted to Fedora 26,
> > > the currently supported version, and should be complete.
> > > The archlinux instructions are quite out of date and the README definitely
> > > needs to be updated.
> > > I'm not sure what you mean by OS version, or most of your last
> > > paragraph. Can you clarify?
> > 
> > Sorry, I've gone back to your original post and it's clearer.
> > You should be able to build all the templates referenced in the setup
> > program. If you can't, then (barring network problems) it's a bug.
> > Its a moot point whether you should be building some of the older,
> > eol templates, and whether they should be available to build.
> 
> I just added Centos 7 Standard template with the ones that had already built 
> correct and as before it errored out with the following:
> ---
> Building core-admin-client (rpm_spec/qubes-core-admin-client.spec) for 
> centos7 vm (logfile: build-logs/core-admin-client-vm-centos7.log)
> --> build failed!
> reading sources... [ 92%] manpages/qvm-tags
> reading sources... [ 96%] manpages/qvm-unpause
> reading sources... [100%] manpages/qvm-volume
> 
> /home/user/qubes-src/core-admin-client/doc/manpages/qvm-features.rst:91: 
> ERROR: Unknown interpreted text role "py:pbj".
> /home/user/qubes-src/core-admin-client/doc/manpages/qvm-firewall.rst:73: 
> WARNING: Bullet list ends without a blank line; unexpected unindent.
> looking for now-outdated files... none found
> pickling environment... done
> checking consistency... 
> /home/user/qubes-src/core-admin-client/doc/manpages/index.rst:: WARNING: 
> document isn't included in any toctree
> done
> writing... qvm-backup-restore.1 { } Checking arguments for 
> 'qvm-backup-restore'
> 
> Exception occurred:
>   File "/usr/lib64/python2.7/importlib/__init__.py", line 37, in import_module
> __import__(name)
>   File 
> "/home/user/qubes-src/core-admin-client/qubesadmin/tools/qvm_backup_restore.py",
>  line 4
> SyntaxError: Non-ASCII character '\xc3' in file 
> /home/user/qubes-src/core-admin-client/qubesadmin/tools/qvm_backup_restore.py 
> on line 4, but no encoding declared; see 
> http://www.python.org/peps/pep-0263.html for details
> The full traceback has been saved in /tmp/sphinx-err-JOw4sG.log, if you want 
> to report the issue to the developers.
> Please also report this if it w

[qubes-users] Re: qvm-usb is broken in Qubes 4.0 rc4

[Tim W]

On Sunday, February 4, 2018 at 8:50:12 PM UTC-5, Fabrizio Romano Genovese wrote:
> Hello all, 
> 
> When I try to attach my webcam to any appvm, I get the following message:
> 
> Device attach failed: /usr/lib/qubes/usb-import: line 32: 
> /sys/devices/platform/vhci_hcd/status: No such file or directoryNo unused 
> port found!/usr/lib/qubes/usb-import: line 51: 
> /sys/devices/platform/vhci_hcd/attach: No such file or directory
> 
> In the meantime, the devices widget thinks that everything is ok.
> I was able to reproduce this error on two different machines, one upgraded 
> from Qubes 4.0 rc3 and another coming from a fresh install. What should I do?
> 
> Cheers,
> Fab

Does it work with a flash drive as storage device?

-- 
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/b3fc8d8e-7dd8-47b1-939e-865b5858f8b1%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[qubes-users] Re: Clarification on "Include in memory balancing" checkbox

[Tim W]

Yes mostly that makes sense.  I am not cealr on your last part but may be 
reading it incorrectly.  If checking the box should automatically check to 
ensure mem is included in the services list and if not add it then why would it 
also disable mem if it does not find it in the services list?   Seems like its 
staying to do two opposing actions when running the checklist add it  if its 
not found but also disable it if its not found?


Cheers.

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/fe04bfef-87a6-4289-85eb-af24bf037c2b%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[qubes-users] Clarification on "Include in memory balancing" checkbox

[Tim W]

Thats what I also thought but mybknowledge base is merger in this area.  I am 
sure it could be answered quickly on the devel list.

-- 
You received this message because you are subscribed to the Google Groups 
"qubes-users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to qubes-users+unsubscr...@googlegroups.com.
To 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/96978c98-13a1-4241-9d6a-3f28365a633c%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[qubes-users] Re: very frequent crashes (about every other hour)

[Tim W]

That is one of the reasons I returned the first thinkpad 440p w nvida discreet 
and got one with only intel as they got rid of the bios switch to disable one 
or the other.  

I also saw a issue  related to one point Drew mentions. that it would build 
over time with symptoms sucb as yours.   Vms with web browsers left open for 
long periods.  Manily firefox but after a few days the whole system would get 
sluggish even though ram reported was fine.  Closing web browsers more freq 
took care of issues.

To me if you do not have active iommu (intel vt-d) you are castrating qubes 
secuirty.   Still way too many power drain perf issues with discreet nvida imo. 
 Not that its not workable just nvida makes it harder imo deliberately when it 
comes to linux just in general as do a majority of hardware manf.

-- 
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/9c561a8c-a5ca-43c8-be88-fb2162f9fbf0%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [qubes-users] qvm-usb is broken in Qubes 4.0 rc4

[Tim W]

On Monday, February 5, 2018 at 4:24:36 PM UTC-5, Marek Marczykowski-Górecki 
wrote:
> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA256
> 
> On Sun, Feb 04, 2018 at 05:50:12PM -0800, Fabrizio Romano Genovese wrote:
> > Hello all, 
> > 
> > When I try to attach my webcam to any appvm, I get the following message:
> > 
> > Device attach failed: /usr/lib/qubes/usb-import: line 32: 
> > /sys/devices/platform/vhci_hcd/status: No such file or directoryNo unused 
> > port found!/usr/lib/qubes/usb-import: line 51: 
> > /sys/devices/platform/vhci_hcd/attach: No such file or directory
> > 
> > In the meantime, the devices widget thinks that everything is ok.
> > I was able to reproduce this error on two different machines, one upgraded 
> > from Qubes 4.0 rc3 and another coming from a fresh install. What should I 
> > do?
> 
> Install template updates from current-testing repository[1], it's fixed
> there already. Packages will migrate to default repository later today.
> 
> [1] https://www.qubes-os.org/doc/software-update-vm/#testing-repositories
> 
> - -- 
> Best Regards,
> Marek Marczykowski-Górecki
> Invisible Things Lab
> A: Because it messes up the order in which people normally read text.
> Q: Why is top-posting such a bad thing?
> -BEGIN PGP SIGNATURE-
> 
> iQEzBAEBCAAdFiEEhrpukzGPukRmQqkK24/THMrX1ywFAlp4y4sACgkQ24/THMrX
> 1ywuPAf/WaohYYgsEdJQ6XaTCDyONg8VM9xzOV/Wu0/ZlCQFjX6bsKrXMBlx9xL2
> uJhu5McE3kywYKg1QySMTXG8TRFoaaYfxoghYcRknlmHV6nDj72pJfiMm3DscVY8
> mTM47GWyCLXwZL3z1us/VBOQZUM+k2E3lF0Pyh37a/p7bkDeZZz0VVq2BD7jwwAm
> KgAiFybRz2GePo7oyu8SI93Ks8bQJcGfZmqh6SZ1nXxTjQ7Fad4dvPYyBy10tMLh
> bN89RjIQuCG0LN7ZaAB3t0uqltAIpjvv3gu1HCAXKTkkDpBFPbEsRKMKmXclDQij
> mfpbj23mp7Azw7ETTtvdz7LTrmtVxQ==
> =4vQa
> -END PGP SIGNATURE-

Thanks Marek.   

-- 
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/89fe07f8-7633-4ef0-b76c-31f92c0b03eb%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[qubes-users] Re: Clarification on "Include in memory balancing" checkbox

[Tim W]

On Thursday, February 8, 2018 at 4:51:54 PM UTC-5, brenda...@gmail.com wrote:
> On Thursday, February 8, 2018 at 3:32:56 PM UTC-5, Tim W wrote:
> > Yes mostly that makes sense.  I am not cealr on your last part but may be 
> > reading it incorrectly.  If checking the box should automatically check to
> > ensure mem is included in the services list and if not add it then why 
> > would 
> > it also disable mem if it does not find it in the services list?   Seems 
> > like 
> > its staying to do two opposing actions when running the checklist add it  
> > if 
> > its not found but also disable it if its not found?
> 
> Generally: the listing of a qubes service in the services tab allows you to 
> override the default setting for that service. Some services are enabled by 
> default, so if they are not listed they are still enabled. This also applies 
> to the qvm-service tool.
> 
> e.g. meminfo-writer is by default *enabled* on all VMs with the exception of 
> NetVMs (or for R4.0, this would be a VM that "provides network"). So if it is 
> not listed, it is *enabled*.
> 
> Reference #1:
> 
>   From: https://www.qubes-os.org/doc/vm-interface/
>   [[/qubes-service/SERVICE_NAME - subtree for VM services controlled from 
> dom0 
>   (using qvm-service command or Qubes Manager). One of 1, 0. Note that not 
> every 
>   service will be listed here, if entry is missing, it means “use VM 
> default”. 
>   List of currently supported services is in qvm-service man page]]
> 
>  (useful since it points to the man page for qubes-service below...)
> 
> Reference #2:
>   man qvm-service says (manual copy-paste):
> meminfo-writer
>   Default: enabled everywhere excluding NetVM
> 
> So, again: if under services, meminfo-writer is *not listed*, it is *ENABLED*.
> 
> Brendan



Got it thanks for the further explanation.  I was not understanding it 
correctly.  Makes sense now.

Cheers,

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/1d7e27c1-1dbf-4b38-99bf-e49acab9a006%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [qubes-users] Building Qubes 4rc4 iso from source

[Tim W]

On Saturday, February 3, 2018 at 11:39:09 PM UTC-5, awokd wrote:
> On Sun, February 4, 2018 4:21 am, Tim W wrote:
> 
> > packages'. Error: Error downloading packages:
> > Status code: 503 for
> > https://mirrors.fedoraproject.org/metalink?repo=fedora-25=x86_64
> 
> >
> > An issue with the link in the makefile?
> 
> Probably a Fedora repo issue, maybe it's being updated. You might run into
> a bunch of those. All you can do is run "make qubes" again and cross your
> fingers.

Well that royally sucks.  Its not as if the build process is only 5-10 mins.  
That was 30-45 mins to hit that error.

looked at the makefile.fedora and it looks like this section.  Does it look 
correct  I was wondering if something might change with depeciation of f25

ifdef FEDORA_MIRROR
YUM_OPTS += --setopt=fedora.baseurl=$(patsubst 
%/,%,$(FEDORA_MIRROR))/releases/$(subst fc,,$(DIST))/Everything/x86_64/os/
YUM_OPTS += --setopt=updates.baseurl=$(patsubst 
%/,%,$(FEDORA_MIRROR))/updates/$(subst fc,,$(DIST))/x86_64/
endif


Ill try running it yet again.

-- 
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/204984c3-fc0a-407e-9e9d-c274099cd1f2%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [qubes-users] Building Qubes 4rc4 iso from source

[Tim W]

On Saturday, February 3, 2018 at 8:40:27 PM UTC-5, awokd wrote:
> On Sun, February 4, 2018 1:16 am, Tim W wrote:
> > Has anyone accomplished a clean build?
> 
> I've successfuly built 4.0rc3 in a Fedora 26 VM with the following installed:
> sudo dnf install git createrepo rpm-build make wget rpmdevtools dialog
> rpm-sign gnupg dpkg-dev debootstrap python2-sh
> 
> I used the Fedora 26-standard, Debian 9-standard, and whonix-gw & ws
> templates. They should be the safest bets because they ship with Qubes.
> I'll kick off another build in case there's an rc4 regression; haven't
> tried recently.

Thanks will try that as the most basic.  

Did you use ./setup or just run off the master build.conf in examples directory?

-- 
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/fe51473d-e7fc-4034-93e6-d7c5b8610177%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [qubes-users] Building Qubes 4rc4 iso from source

[Tim W]

On Saturday, February 3, 2018 at 9:44:22 PM UTC-5, awokd wrote:
> On Sun, February 4, 2018 2:29 am, Tim W wrote:
> >
> > Thanks will try that as the most basic.
> >
> >
> > Did you use ./setup or just run off the master build.conf in examples
> > directory?
> 
> ./setup. Mostly followed the same steps as here
> https://github.com/QubesOS/qubes-issues/issues/3426, just skip the text
> file edits and choose 4.0 instead of 3.2.

Thanks am starting the process now.  I always prefer to build my own OS and 
prog from source whenever possible.  Makes updating a bit more tedious but it 
keeps me more uptodate and with less possible points for code to be altered + 
if I can't build something it concerns me.

-- 
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/53c81e9a-c6b3-4fb6-9ba1-67a92af32e2e%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [qubes-users] Building Qubes 4rc4 iso from source

[Tim W]

On Saturday, February 3, 2018 at 9:56:06 PM UTC-5, Tim W wrote:
> On Saturday, February 3, 2018 at 9:44:22 PM UTC-5, awokd wrote:
> > On Sun, February 4, 2018 2:29 am, Tim W wrote:
> > >
> > > Thanks will try that as the most basic.
> > >
> > >
> > > Did you use ./setup or just run off the master build.conf in examples
> > > directory?
> > 
> > ./setup. Mostly followed the same steps as here
> > https://github.com/QubesOS/qubes-issues/issues/3426, just skip the text
> > file edits and choose 4.0 instead of 3.2.
> 
> Thanks am starting the process now.  I always prefer to build my own OS and 
> prog from source whenever possible.  Makes updating a bit more tedious but it 
> keeps me more uptodate and with less possible points for code to be altered + 
> if I can't build something it concerns me.

It failed with below:


Downloading Packages:

The downloaded packages were saved in cache until the next successful 
transaction.
You can remove cached packages by executing 'dnf clean packages'.
Error: Error downloading packages:
  Status code: 503 for 
https://mirrors.fedoraproject.org/metalink?repo=fedora-25=x86_64
/home/user/qubes-builder/qubes-src/builder-fedora/Makefile.fedora:111: recipe 
for target 'dist-build-dep' failed
make[2]: *** [dist-build-dep] Error 1
make[2]: Leaving directory '/home/user/qubes-builder'
Makefile.generic:156: recipe for target 'packages' failed
make[1]: *** [packages] Error 1
make[1]: Leaving directory '/home/user/qubes-builder'
Makefile:224: recipe for target 'core-libvirt-dom0' failed
make: *** [core-libvirt-dom0] Error 1


An issue with the link in the makefile?

-- 
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/81dd9d4b-d06d-4104-8f39-7105c1b8c5c7%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[qubes-users] Re: Building Qubes 4rc4 iso from source

[Tim W]

Also when I ran setup script it required PyYaml and that was also shown 
in https://www.qubes-os.org/doc/qubes-builder/ Building Qubes From Scratch 

Then you have the build directions that there is notes to follow the Archlinux 
directions for using the builder tools and they do not have them but then it 
includes python.sh rather than python2.sh .  The latter is definitely needed.

Then finally in the README.md file in the qubes-builder which you are directed 
to read it has you install perl-open but not dpkg-dev debootstrap and a few 
others.  So we are basically given directions to go to at least 3 different 
places that all have from slightly different to completely different 
instructions for building qubes.

IMHO for the advanced user who wants to build qubes from source the ./setup 
script is by far the easiest to follow as it being a all inclusive script 
handles many steps for you in a nice basic gui.  Issue is we need to have some 
very basic steps of what will work with each OS version.  It would only take 
10-15 min to update a markup page for each os.  Everything is there except what 
works with what OS and frankly that's all in terms of instructions that should 
have to change ever in qubes current xen based format.  If a dev could even 
just post a list of what templates work with the version in the group I or 
others can easily update the doc page.  I have helped in that area before as 
its one area IMO any and all qubes users can help out with and give back to the 
project. 

-- 
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/a8035610-fee7-42e8-90aa-a25ebfb337d7%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [qubes-users] Building Qubes 4rc4 iso from source

[Tim W]

On Sunday, February 4, 2018 at 12:25:46 AM UTC-5, awokd wrote:
> On Sun, February 4, 2018 4:48 am, Tim W wrote:
> > On Saturday, February 3, 2018 at 11:39:09 PM UTC-5, awokd wrote:
> >
> >> On Sun, February 4, 2018 4:21 am, Tim W wrote:
> >>
> >>
> >>> packages'. Error: Error downloading packages: Status code: 503 for
> >>> https://mirrors.fedoraproject.org/metalink?repo=fedora-25=x86_64
> >>>
> >>
> >>>
> >>> An issue with the link in the makefile?
> >>>
> >>
> >> Probably a Fedora repo issue, maybe it's being updated. You might run
> >> into a bunch of those. All you can do is run "make qubes" again and
> >> cross your fingers.
> >
> > Well that royally sucks.  Its not as if the build process is only 5-10
> > mins.  That was 30-45 mins to hit that error.
> >
> > looked at the makefile.fedora and it looks like this section.  Does it
> > look correct  I was wondering if something might change with depeciation
> > of f25
> 
> I know, it takes me around 6 hours for a fresh download and full build.
> Another thing you can try if you're frequently getting download issues
> (status code 503 is server issue, not missing file) is to build one group
> of components at a time instead of the full list (which "make qubes"
> does).
> If you want to try that instead, do "make help" and look for the list of
> components towards the end. It's like 10 lines long. Then start copying
> and pasting them into make, one batch at a time, like "make vmm-xen
> core-libvirt core-vchan-xen" for the first batch. That way if it fails you
> don't have to go so far back. Make sure to run them in order.

great idea.  I had done that on templates when working out issues back before 
we all got archlinux building well.  Did not think of if for this.  So far this 
time its still running on the build so hopefully in a few hours I will have an 
iso.  We will see.  

After that I think I will start adding in other templates to make a list of 
what works.   As I can leave it to do its thing will not be a big waste of 
time.  I am thinking minimal templates should also work.  Then its onto Centos. 
 I prefer it leaps and bounds over Fedora.  IMO its the ideal dom0 if we need 
to stick to rpm based with its long LTS.  Now with the longer linux kernel 
support it will go great together for a long term stable system without having 
to upgrade.

-- 
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/702c85d1-1130-4c4f-9c31-f1e9a68b0ca5%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[qubes-users] Building Qubes 4rc4 iso from source

[Tim W]

Has anyone accomplished a clean build?

I have tried with a standard builder.conf as well as using the ./setup script 
to create the builder.conf.

Doing the builder.conf from example when I uncomment whonix I am asked for git 
username and password during #make get-sources for that.   Even with it removed 
during #make qubes I get failures.

Using ./setup I have tried numerous combos of the various templates offered 
removing ones that create errors.  Still I can not get a clean build.  It maybe 
because I am picking templates that while listed do not actually work with 4.0. 
  If this is the case which templates should work with building 4.0?

"Example last time I had it fail during the initial build steps of FC26+fully 
loaded with error:

Building template fc26 (logfile: build-logs/template-fc26.log)...
Makefile:297: recipe for target 'template-local-fc26+fullyloaded' failed
make: *** [template-local-fc26+fullyloaded] Error 1"

I did have some null failures but I think it had to do with misdirection of 
log.txt as it did not stop the build example below:

" Installing core RPM packages...
install-info: No such file or directory for /dev/null
install-info: No such file or directory for /dev/null
install-info: No such file or directory for /dev/null
install-info: No such file or directory for /dev/null
Failed to connect to bus: No such file or directory
Failed to set locale, defaulting to C
Running in chroot, ignoring request.
-> Installing package groups...
Failed to set locale, defaulting to C"

All I really care about in the end is a way to get a clean build of the latest 
release being 4.0rc4.

I did not have these issues before building 3.1 and 3.2.

Ideally I would like to build an iso with FC25, Fc26, Debian Stretch, Whonix, 
Centos7 would like the standard and minimal where they are available.  Not sure 
exactly what is difference between the standard Template and fully-loaded one.  
I get minimal but did not realize there were fully loaded and standard. I tried 
picking all of them but got failures.  After removing a number of them and 
still getting failures I decided it was time to ask some questions as my 
search-fu turned up nothing helpful.


I am working in a 3.1 fc23 standalone VM  in it phython2.sh is not found in 
repo so I loaded it as a rpm.  If you load only python.sh you get error looking 
for python2.sh  Other than that I have not seen anything error specific to 
building in FC23


Tim
Cheers,

-- 
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/5a317d6c-9e83-4996-be67-abf8af70873a%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [qubes-users] Can't seem to build qubes 3.2

[Tim W]

Are you running the ./setup or using the build.conf example?  If the later look 
at awokd's link and follow those steps.  

https://github.com/QubesOS/qubes-issues/issues/3426


That is how I have been building qubes iso and separate templates since ver 
3.1.  Do not follow any of the steps to edit conf files etc in the linked 
instructions above.  Just follow the cmds as those issues have been fixed.   

Pick fc26 (optional fc26minimal) stretch (optional stretch minimal) and the 2 
whonix templates.  You tech can add all the fc26 and Stretch template choices 
as they all should build based off my tests results.  You would need more disk 
space though.  I could be off but I think adding 5 gig per extra template you 
add should keep you with enough build space.  Start at 60 gig for standard 
build and go up from there.  They build in fc23 fc25 i have seen people post 
issues using fc27 but have no idea if its version related or not.

-- 
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/b392158d-f3a4-4d31-a80f-d2a9a1ade1ad%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [qubes-users] Can't seem to build qubes 3.2

[Tim W]

I have been having isses with fedoras repo over the last few days while 
compiling both 3.2 and 4.0.   I have stopped using make qubes all together and 
instead compile the packages in small groups or individually.  I can then redo 
a package a few times without starting over.  I have been able to compile a 
number of different template configs.

So far it seems the non standard templates fail with python script or config 
errors.  Fedora 25 works other than the fc25fullyloaded template.   Centos 
fails as does Xenial Ubuntu.  I had issues with archlinux as well but have not 
tried it package by package so it might work.   They may build fine as 
templates only but they do not when rolled into a qubes os iso build.  

Im putting together a list of the failures to post once Im done so we can look 
over and fix the issues.  

-- 
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/731060d9-fbfc-45db-b97a-89beee2b245d%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[qubes-users] Re: Qubes 4.0 without IOMMU/VT-d/AMD-Vi or Interrupt Remapping

[Tim W]

5he nice thing going forward is most newer processors are coming with the iommu 
etc where just 2 years ago it was at least 2x less choices.   The real issue 
these days is making sure the bios/efi software is supporting it to the 
standard and not some half baked abortion of what it should be.   Its one of 
the reasons the lenovo thinkpads are the first choice.  If they had not 
switched away from coreboot or allowing it to be swapped in it would be about 
as good as you could get with an current cpu.  

My 440p has been great running qubes and fully supports 4.0 as well.  16g ram 
has been plenty  for a laptop (not workstation replacement).

For a workstation I would rather build one so I could have as close to an ideal 
config as possible but certainly not cheap $ option.

-- 
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/19c78800-bc6a-49e3-b674-9af1b8bb5bbc%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [qubes-users] Do you use Qubes OS as your main OS on primary PC? What kind of work do you get done on it?

[Tim W]

Major  version chanves require wipe and install not upgrade such as 3.2 to 4.0. 
 Now 3.0 thru 3.2 could be done upgrade patg but honestly I think as 
infrequently as new versions come out it worth doing a wipe and install fo 
ensure a nice clean functioning install with no legacy fragments left anywhere.

Cheers.

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/ae97c186-06af-461a-a6e9-44a3a0244106%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[qubes-users] Re: unikernel-firewall: anyone tried this / anyone who wants to help/ already hvm template to download?

[Tim W]

On Wednesday, November 1, 2017 at 7:38:40 AM UTC-4, ludwig jaffe wrote:
> Hi I found an interesting approach of having a small unikernel firewall,
> that does not eat up too much RAM, especially useful for a laptop and also
> as there is a different ip-stack than in Linux one has an advantage against
> common errors:
> (if there is a flaw in the linux kernel it affects sys-net and sys-firewall,
> if there is a flaw in uni-kernel-firewall it only affects the firewall and if
> there is a flaw in the kernel then it affects sys-net and not sys-firewall!)
> 
> look here for the project:
> http://roscidus.com/blog/blog/2016/01/01/a-unikernel-firewall-for-qubesos/ 
> https://github.com/talex5/qubes-mirage-firewall.git
> 
> 
> would be nice to have the mirage-os based firewall as an install option,
> by downloading a signed template with a tested mirage-os based firewall.
> 
> Is there anyone who has experience with it?
> I would like to try it and help developing it further. Who else wants?
> 
> Cheers,
> 
> Ludwig

Tth

-- 
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/dcf7ce83-cc97-481d-a646-e17cbc71051f%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[qubes-users] Re: Leaky Through Faraday Cage Shielding

[Tim W]

On Sunday, February 11, 2018 at 1:06:06 PM UTC-5, David L. Craig wrote:
> https://thehackernews.com/2018/02/airgap-computer-hacking.html
> 
> Dang!  Be certain your vaults cannot be compromised.
> -- 
> 
> May the LORD God bless you exceedingly abundantly!
> 
> Dave_Craig__
> "So the universe is not quite as you thought it was.
>  You'd better rearrange your beliefs, then.
>  Because you certainly can't rearrange the universe."
> __--from_Nightfall_by_Asimov/Silverberg_

that is a lab only hack and makes some big assumptions to be successful.  
Secondly, they are careful to only say faraday cage not official SCIF yet tries 
to insinuate this. The pic diagram on the left is not even close to how a SCIF 
or even basic faraday cage would be built.  Its not a Faraday cage is one side 
is some standard office wall. A SCIF is a complete enclosure on all sides 
including top and bottom.  Official SCIFs are Tempest certified enclosure which 
is far more than a basic faraday cage. SCIFs and TIPS are GSA/NSA grade 5 
spec'd and also deal with heat transmissions.  

Second the hack requires not only having access to the area around the 
enclosure but to the computer itself and further that it allows for successful 
upload the initial transmission side of the hack which has to be done 
physically thru conventional means. Then a receiver has to be in some close 
proximity to the SCIF enclosure/building to pickup these extremely weak 
transmissions which a real TIPS SCIF to current spec would defeat.   

I don't know how many people have seen or used top grade TIPS/SCIF, but this is 
not going to happen without it evolving a high level conspiracy.  No leaving a 
bunch of flash drives in the parking lot is going to work.  

-- 
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/56886cae-3aa8-429f-9097-231e87e75881%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[qubes-users] Re: If you get "no authenticators available" with mutt

[Tim W]

On Friday, February 9, 2018 at 12:32:21 PM UTC-5, Konstantin Ryabitsev wrote:
> If you are trying to use mutt with the default Fedora-26 template and 
> can't figure out why authenticated smtp sending is giving you a "No 
> Authenticators Available" error, you need to install cyrus-sasl-plain.
> 
> Drove me half-mad before I figured that out. Hopefully it saves you a 
> bunch of clicks (and hair).
> 
> -K

thank you   that saved me the time of doing a bunch of searching and forum 
reading.

-- 
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/80737693-e515-4996-9233-587ee4ac7b4b%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[qubes-users] Re: Three systems (linux)

[Tim W]

On Friday, February 9, 2018 at 6:18:38 PM UTC-5, 
bm-2ctrx1tl5lg8cfa...@bitmessage.ch wrote:
> I solved the problem. The thread can be removed.

Just mark the posts completed and it will show completed in the listed

-- 
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/61af5d1d-3d35-4a89-915c-64bf0b061ee4%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[qubes-users] Building Centos template conflict error?

[Tim W]

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.  

-- 
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/ab93793f-ebc9-4869-aba9-ab962625a2a9%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

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

[Tim W]

On Tuesday, February 13, 2018 at 5:07:32 PM UTC-5, Frédéric Pierret (fepitre) 
wrote:
> 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.
> 
> The template for CentOS in Q4 is still not completely achieved. I still need 
> time to fix several things.

But the error I am getting is for Q-3.2 not 4.0.  Its listed in my first post, 

I had not included the 4.0 errors as I thought it might just be a needed update 
of software version or module but here they are from 4.0 in case they are of 
any use to you.

Error: Package: python3-qubesimgconverter-4.0.15-1.el7.centos.x86_64 
(template-builder-repo)
   Requires: python3-pillow
Error: Package: python2-qubesimgconverter-4.0.15-1.el7.centos.x86_64 
(template-builder-repo)
   Requires: python2-numpy
Error: Package: python2-qubesimgconverter-4.0.15-1.el7.centos.x86_64 
(template-builder-repo)
   Requires: python2-pillow
Error: Package: python3-qubesimgconverter-4.0.15-1.el7.centos.x86_64 
(template-builder-repo)
   Requires: python3-numpy

Shouldn't 3.2 still be buildable ?

Instead in 3.2 I am getting the following during $ make linux-template-builder  
:
 
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 

-- 
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/1279f026-e979-456c-80e8-e9d34f73ee23%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[qubes-users] Re: Privacy in Qubes

[Tim W]

On Wednesday, September 20, 2017 at 4:47:16 PM UTC-4, Yuraeitha wrote:
> On Wednesday, September 20, 2017 at 12:50:46 PM UTC, Dominique St-Pierre 
> Boucher wrote:
> > On Wednesday, September 20, 2017 at 8:27:40 AM UTC-4, cooloutac wrote:
> > > On Monday, September 18, 2017 at 11:02:50 PM UTC-4, Person wrote:
> > > > Let's say you have an online identity that you want to keep separate 
> > > > from your personal information. On Qubes, is it possible to keep i 
> > > > information completely separate without physical separation? I have 
> > > > considered using a separate OS virtualized in Qubes, but it may 
> > > > possibly leak the same device data. Multibooting with Qubes is also not 
> > > > the safest idea. 
> > > > 
> > > > What is the best way to keep online information from being traced back 
> > > > to you on Qubes?
> > > 
> > > Not really sure what you are asking, or what information specifically.   
> > > Keeping information separate is the general purpose of Qubes.  One vm 
> > > doesn't know what data is on the other one.
> > > 
> > > If you are talking about keeping your identity hidden from the internet.  
> > > Just don't let the vm connect to the internet?
> > > 
> > > As far as information like device id's,  that would depend on the program 
> > > you are connecting to the internet and if it gathers such information.  I 
> > > really don't know if what core linux processes do this.  Browsers prolly 
> > > do yes?
> > > 
> > > In general, hiding your identity is not really something thats Qubes 
> > > specific.  Use multiple whonix qubes with tor browser?  Don't log in the 
> > > same online identities on the same vm?
> > 
> > If you are talking about the first the identity of your computer, that will 
> > always be the same hostname, mac address if you connect both vm through the 
> > same network card. If you have 2 network card (and different sys-net), you 
> > can maybe have the traffic through one card for one ID and the other ID 
> > through the other card but if you are using it at home on the same lan, I 
> > don't see the point. But doing it on a public wifi and using 2 differents 
> > network card (and different sys-net vm) you can have 2 different session on 
> > the same website and I don't see a way from the server side to figure out 
> > that you are doing it from the same computer.
> > 
> > Hope I make sense!!!
> > 
> > Dominique
> 
> I second Dominique here, this is what I would do too if I wanted to maximize 
> anonymity. However be mindful that it's still risky if its a matter of life 
> and death, or anything other really serious/important. There is always a 
> remote chance that something can be used to track back to you, be it 
> something brand new, zero-day exploits, or what else hidden tricks is out 
> there. Although these is mostly only used against high-profile targets, and 
> typically, or most likely not,on your everyday internet users.
> 
> For example virtualization isn't perfect. To my knowledge, this is one of the 
> reasons Qubes is switching from PV to HVM. And even then, HVM seems to only 
> be a temporay solution, as while it's better than the current PV, it isn't 
> perfect either. Generally, you're in deep trouble if someone is hunting you 
> as a high-profile, but if its the average joe-hacker? Probably not. >From 
> what I can gather, Qubes attacks are difficult to pull off, so much that it 
> hasn't been observed in the wild. However one of Qubes's weakpoints is the 
> lack of reward pools for white-hat hackers who hunt for bugs and weakenesses, 
> although it may be solved soon through donations I think? Anyway, just be 
> careful, don't do anything that you can't pay for afterwards, be it your 
> life, prison, or what else may be hunting you.
> 
> Also to do Qubes justice, it's still pretty darn secure. It requires exotic 
> and probably difficult hacks to get through, such as hacking one DomU and 
> mess up your memory in other to break into another DOmU, and thereby 
> indirectly get access to Dom0, or something like that. Presumably the Qubes 4 
> system is much better protected against this kind of difficult but 
> theoretical possible attack, than Qubes 3.2 is. 
> 
> Then again, I'm no security expert, take my words with some salt. But 
> definitely don't believe Qubes has perfect isolation, it doesn't, not with 
> modern technology anyway. However it's a massive leap in the right direction 
> for better security. 
> 
> Furthermore, be extremely mindful of user-habits and which websites you visit 
> within the same Tor sessions. If someone is specifically targeting you, they 
> might be able to do simple detective work to figure out who you are. Be sure 
> to make a new session before you do anything that can tie your identity to 
> anything which must be anonymous in the future. It can even be the 
> combination of websites you visit, fingerprints in the Tor browser (they are 
> hard to get rid off, even for Tor/Whonix). Never turn on 

[qubes-users] Re: Privacy in Qubes

[Tim W]

On Friday, February 9, 2018 at 4:33:00 AM UTC-5, Yuraeitha wrote:
> On Friday, February 9, 2018 at 7:09:32 AM UTC+1, Tim W wrote:
> > On Wednesday, September 20, 2017 at 4:47:16 PM UTC-4, Yuraeitha wrote:
> > > On Wednesday, September 20, 2017 at 12:50:46 PM UTC, Dominique St-Pierre 
> > > Boucher wrote:
> > > > On Wednesday, September 20, 2017 at 8:27:40 AM UTC-4, cooloutac wrote:
> > > > > On Monday, September 18, 2017 at 11:02:50 PM UTC-4, Person wrote:
> > > > > > Let's say you have an online identity that you want to keep 
> > > > > > separate from your personal information. On Qubes, is it possible 
> > > > > > to keep i information completely separate without physical 
> > > > > > separation? I have considered using a separate OS virtualized in 
> > > > > > Qubes, but it may possibly leak the same device data. Multibooting 
> > > > > > with Qubes is also not the safest idea. 
> > > > > > 
> > > > > > What is the best way to keep online information from being traced 
> > > > > > back to you on Qubes?
> > > > > 
> > > > > Not really sure what you are asking, or what information 
> > > > > specifically.   Keeping information separate is the general purpose 
> > > > > of Qubes.  One vm doesn't know what data is on the other one.
> > > > > 
> > > > > If you are talking about keeping your identity hidden from the 
> > > > > internet.  Just don't let the vm connect to the internet?
> > > > > 
> > > > > As far as information like device id's,  that would depend on the 
> > > > > program you are connecting to the internet and if it gathers such 
> > > > > information.  I really don't know if what core linux processes do 
> > > > > this.  Browsers prolly do yes?
> > > > > 
> > > > > In general, hiding your identity is not really something thats Qubes 
> > > > > specific.  Use multiple whonix qubes with tor browser?  Don't log in 
> > > > > the same online identities on the same vm?
> > > > 
> > > > If you are talking about the first the identity of your computer, that 
> > > > will always be the same hostname, mac address if you connect both vm 
> > > > through the same network card. If you have 2 network card (and 
> > > > different sys-net), you can maybe have the traffic through one card for 
> > > > one ID and the other ID through the other card but if you are using it 
> > > > at home on the same lan, I don't see the point. But doing it on a 
> > > > public wifi and using 2 differents network card (and different sys-net 
> > > > vm) you can have 2 different session on the same website and I don't 
> > > > see a way from the server side to figure out that you are doing it from 
> > > > the same computer.
> > > > 
> > > > Hope I make sense!!!
> > > > 
> > > > Dominique
> > > 
> > > I second Dominique here, this is what I would do too if I wanted to 
> > > maximize anonymity. However be mindful that it's still risky if its a 
> > > matter of life and death, or anything other really serious/important. 
> > > There is always a remote chance that something can be used to track back 
> > > to you, be it something brand new, zero-day exploits, or what else hidden 
> > > tricks is out there. Although these is mostly only used against 
> > > high-profile targets, and typically, or most likely not,on your everyday 
> > > internet users.
> > > 
> > > For example virtualization isn't perfect. To my knowledge, this is one of 
> > > the reasons Qubes is switching from PV to HVM. And even then, HVM seems 
> > > to only be a temporay solution, as while it's better than the current PV, 
> > > it isn't perfect either. Generally, you're in deep trouble if someone is 
> > > hunting you as a high-profile, but if its the average joe-hacker? 
> > > Probably not. From what I can gather, Qubes attacks are difficult to pull 
> > > off, so much that it hasn't been observed in the wild. However one of 
> > > Qubes's weakpoints is the lack of reward pools for white-hat hackers who 
> > > hunt for bugs and weakenesses, although it may be solved soon through 
> > > donations I think? Anyway, just be careful, don't do anything that you 
> > > can't pay for afterwards, be it your life, prison, or what else may be 
> > >

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

[Tim W]

On Wednesday, February 14, 2018 at 11:46:32 AM UTC-5, Frédéric Pierret 
(fepitre) wrote:
> Le mercredi 14 février 2018 06:30:37 UTC+1, Tim W a écrit :
> > On Tuesday, February 13, 2018 at 5:07:32 PM UTC-5, Frédéric Pierret 
> > (fepitre) wrote:
> > > 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.
> > > 
> > > The template for CentOS in Q4 is still not completely achieved. I still 
> > > need time to fix several things.
> > 
> > But the error I am getting is for Q-3.2 not 4.0.  Its listed in my first 
> > post, 
> > 
> > I had not included the 4.0 errors as I thought it might just be a needed 
> > update of software version or module but here they are from 4.0 in case 
> > they are of any use to you.
> > 
> > Error: Package: python3-qubesimgconverter-4.0.15-1.el7.centos.x86_64 
> > (template-builder-repo)
> >Requires: python3-pillow
> > Error: Package: python2-qubesimgconverter-4.0.15-1.el7.centos.x86_64 
> > (template-builder-repo)
> >Requires: python2-numpy
> > Error: Package: python2-qubesimgconverter-4.0.15-1.el7.centos.x86_64 
> > (template-builder-repo)
> >Requires: python2-pillow
> > Error: Package: python3-qubesimgconverter-4.0.15-1.el7.centos.x86_64 
> > (template-builder-repo)
> >Requires: python3-numpy
> > 
> > Shouldn't 3.2 still be buildable ?
> > 
> > Instead in 3.2 I am getting the following during $ make 
> > linux-template-builder  :
> >  
> > 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
> 
> Sorry I read too fastly. The errors in Q4 for the python dependencies are 
> exactly some of the reasons why it is long to do the template. Some python3 
> packages are not built for CentOS...For you problem I need to perform the 
> rebuild with the latest version of r3.2 packages. I keep you in touch.


Sounds good.  I figured that was the issue for the Q4 but Q3.2 error was the 
one that surprised me as its been a good build in the past.

Just an FYI I am building this in F23 but did bring in the correct python2.sh.  
Have had no issues building standard Q3.2 and 4.0 ISOs.

-- 
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/ab840e15-d731-433a-85dc-56aee698828c%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [qubes-users] cannot build ubuntu template

[Tim W]

There is a python2.sh rpm if you do a google search under centos I found and 
use and have been sucessfully building iso and templates.  But there is an 
issue I came across that started 5 or so days ago at least building iso that 
fails on the stretch standard build.   Further the centos 7 does not build 
correctly for 3.2 either now so maybe its effecting all but fedora templates at 
this point but a ticket is open on it.

Again not sure if it effects the zesty but as they are all debain based it 
might.   The 4.0 issues may just not be updated yet but 3.2 should have worked 
as they have in the past so an update/s have caused this.

-- 
You received this message because you are subscribed to the Google Groups 
"qubes-users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to qubes-users+unsubscr...@googlegroups.com.
To 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/d5d3b1b6-1f4a-4a89-bfe3-5f2f30b1f09c%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[qubes-users] Re: Start VMs on boot before user login (Qubes OS 4.0rc4)

[Tim W]

Make sure there is no way to softboot\power cycle the box as with sed opal2 hw 
encrypt drives they will stay unlocked until either manual locked or power loss 
state i.e. true power cycle.   I run  Samsu. 850pro  But still run luks as a 
precaution to some tricks to softboot a locked powered on system.

-- 
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/983a6244-a504-4e56-b626-9c8f5e501b46%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [qubes-users] cannot build ubuntu template

[Tim W]

Yes I agree it would be best ifnthe unsupported templates were commented out 
with a notation in the doc of it incase some reason it needs to be built.   Its 
frustrating when you see 15 + template choices in the s ript but really only 6 
actually work.   The config may aslo ideally be adjusted so template choices 
are different for 3.2 and 4.0 to reflect the currently supported ones.   
Currently I have found that as part of an iso build none of the none standard 
templates will build correctly.   I can only make a qubes iso using fedora and 
debain whonix templates.  Archlinux. Ubuntu, Centos all error out.  On 4.0 even 
fc23 errors out.  Normally not a big deal but its nice to be able to build a 
kernel for 3.2 if you have dupli ate laptops.  I like ha ing active templates 
for current dom0 fc versions regardless it being in 4.0 or 3.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/6ac39a1c-84b2-4264-808d-38546c6d4ad0%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

[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] HTTP proxy & firewall woes

[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.

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

[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.

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

[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: Yubico FIDO U2F Security Key and Qubes

[Tim W]

On Sunday, February 18, 2018 at 3:17:39 PM UTC-5, Yuraeitha wrote:
> On Sunday, February 18, 2018 at 3:51:00 AM UTC+1, William Bormann wrote:
> > On a lark, I purchased a Yubico FIDO U2F Security key.  It's an inexpensive 
> > USB token that can be used for two-factor authentication for Gmail and 
> > Facebook, among others.  I'd like to use it on my Qubes RC4 system.
> > 
> > I've read the USB documentation, but thought I'd see if somebody else 
> > running Qubes has managed to get this working as advertised on their 
> > system. The current path that seems most promising is to bring up SYS-USB, 
> > but I have some concerns about doing this since my keyboard and mouse are 
> > both usb devices.
> > 
> > Can anyone reply with a "hand waving" set of steps I should follow?  I 
> > would greatly appreciate hearing your solution.
> 
> I did not yet get around to testing it out for locking down Qubes my self 
> just yet, but there should be quite a lot of people who managed to. Consider 
> that there are at least a good amount of people wanting this, and generally 
> you see people posting about whether to do it or not (like your post), over 
> people who somehow messed it up and are locked out of their system. 
> 
> From that, I'd deduce that it is probably safe. But you may want to do backup 
> first, at least of your most important AppVM's, just in case something should 
> go south. You never know, whatever can go wrong, will eventually go wrong, as 
> the saying goes.
> 
> Also for what purposes? LUKS disk decryption? Qubes password login/logout 
> when insert/retracting the Yubi-key? Third-party services in AppVM's?
> 
> But having said that, I doubt it's a big issue, especially not if you backup 
> first. Also from what I can read, your old password still works, in case the 
> key isn't working anymore, or is lost/stolen. This isn't a measure against 
> cracking, but a measure against people looking over a persons shoulder, or if 
> sitting under a camera, stuff like that where the password can be stolen. 
> Although of course, it can also servee as a means to memorize a crazy long 
> strong password with high entropy, which makes cracking your drive even 
> harder.
> 
> Whatever the case, you should probably have a means to remember a long random 
> password with strong entropy, in case you loose your hardware key, for 
> example write it on a piece of paper and hide it inside a wall (or something 
> crazy like that). You can alaos backup the hardware key's seed, which is 
> recommended in case you loose the key and need a new key with same 2nd 
> factoring credentials.
> 
> Essentially, it likely more boils down to how you handle your key, and how 
> you prevent loosing it, or exposing it to potential attackers in the physical 
> world. Just search these google mails, you probably won't find many having 
> issues, and instead find people asking questions before they start using it


I do not think he wants this for qubes luks login or even Qubes user login but 
for 2 factor auth pin such as google auth or better yet oathtool.  This should 
be much easier.

-- 
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/0fcdabba-283b-471c-95ea-9d870ea1f0a0%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[qubes-users] Re: Installing Qubes 4 with petitboot

[Tim W]

On Monday, February 19, 2018 at 1:25:51 PM UTC-5, qube...@go-bailey.com wrote:
> I have a new KCMA-D8 based machine with petitboot installed. When I 
> attempt to boot from the Qubes 4 DVD, the install media is not 
> recognized by petitboot. Other installation media that I've tried, like 
> a Ubuntu CD, are recognized and I'm able to boot.
> 
> I've attempted to boot using a new manual entry in petitboot.
> 
> That has been somewhat successful as I've been able to get to the Qubes 
> loading screen but eventually it just stops loading (no errors, etc.).
> 
> I suspect the problem is having the proper entires in my manual entry.
> 
> Currently I have:
> 
> kernel - /isolinux/vmlinuz
> initrd - /isolinux/initrd.img
> boot arguments - append xen.gz console=none --- vmlinuz 
> inst.stage2=hd:LABEL=Qubes-R4.0-rc4-x86_64 i915.preliminary_hw_support=1 
> quiet rhgb --- initrd.img
> 
> based on what I could find in the DVD's isolinux folder.
> 
> Not sure if that is what should be used. Can anyone with a KCMA-D8 or 
> similar setup with petitboot shed any light?
> 
> Thanks in advance.

Did you try a different install DVD not CD?  I ask as I recall a fedora bug 
from awhile ago (fc21 2014/15ish) with petitboot where it would not recognize 
specifically a DVD install media to show up in the boot list.  It had to be 
done manually as you have done.  It has to do with how it reads grub.  It did 
not have support ['FOR' loops] in grub.conf/grub2.conf

This at least would confirm if the issue is specific to Qubes installer which 
is just a slightly modified anaconda installer i.e. fedora SOP (less likely) or 
an issue with petitboot handling of DVD mentioned above.

Here is what is needed to be added to petitboot code and speaks to the issue:

http://git.ozlabs.org/?p=petitboot;a=commit;h=1b272c7d47390077eee0a0638329b1a7df521329


What version of petitboot do you have?  It should print something like this: 
dev.20141013 or maybe 32e2eac7  ?  You could look to confirm you are using a 
version that had these changes applied.  Confirm those additions were actually 
add as well.  I only looked quickly so did not confirm.

I know you maybe set on DVD for a some reason i.e. extra security; but honestly 
USB has for years been the most trouble-free way to install Qubes.


Sorry I can not be more help but you could check the grub.conf from a USB 
install stick after you confirm it works for your setup and does not fail at 
same point

-- 
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/13d0fd7a-2b94-42fe-94c9-d16903880baa%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [qubes-users] Explain the error building 3.2?

[Tim W]

On Friday, February 16, 2018 at 3:02:44 PM UTC-5, awokd wrote:
> On Fri, February 16, 2018 3:33 pm, 'awokd' via qubes-users wrote:
> > On Fri, February 16, 2018 9:43 am, Tim W wrote:
> >
> >
> >> The last two days I have been having issues building 3.2 have not tried
> >>  4.0 yet.
> >>
> >
> >> I get the the following errors in the template-stretch.log file. The
> >> Component fails on the stretch standard template build.  All the Fedoras
> >>  are good has not gotten to whonix yet for that component.
> >
> >> Installing new version of config file /etc/fstab ...
> >> chown: cannot access '/home_volatile/user': No such file or directory
> >> dpkg: error processing package qubes-core-agent (--configure):
> >> subprocess installed post-installation script returned error exit status
> >> 1
> >> dpkg: dependency problems prevent configuration of
> >> qubes-input-proxy-sender:
> >> qubes-input-proxy-sender depends on qubes-core-agent (>= 3.0.25);
> >> however:
> >> Package qubes-core-agent is not configured yet.
> >>
> >
> > My build finally finished running; got the same fatal error you did.
> 
> Might be some kind of interaction between
> https://github.com/QubesOS/qubes-core-agent-linux/pull/81/commits/41f568766f36e7f7588c14490196c906e57a2c22
> (merged 4 days ago) and
> https://github.com/QubesOS/qubes-core-agent-linux/commit/00e846bbbe581aceeeaf4a8369748d4ff450b1b0.
> 
> Want to open an issue on it?

Yes I think so or at least I will post it over on devel.  Those update I think 
are likely the root of it.  Maybe something small but the errors seem to fit.

I will post it over on dev and git.

-- 
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/de336c94-89d9-4ffa-9a2f-972ea45832b3%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [qubes-users] Explain the error building 3.2?

[Tim W]

On Friday, February 16, 2018 at 6:10:32 PM UTC-5, Tim W wrote:
> On Friday, February 16, 2018 at 3:02:44 PM UTC-5, awokd wrote:
> > On Fri, February 16, 2018 3:33 pm, 'awokd' via qubes-users wrote:
> > > On Fri, February 16, 2018 9:43 am, Tim W wrote:
> > >
> > >
> > >> The last two days I have been having issues building 3.2 have not tried
> > >>  4.0 yet.
> > >>
> > >
> > >> I get the the following errors in the template-stretch.log file. The
> > >> Component fails on the stretch standard template build.  All the Fedoras
> > >>  are good has not gotten to whonix yet for that component.
> > >
> > >> Installing new version of config file /etc/fstab ...
> > >> chown: cannot access '/home_volatile/user': No such file or directory
> > >> dpkg: error processing package qubes-core-agent (--configure):
> > >> subprocess installed post-installation script returned error exit status
> > >> 1
> > >> dpkg: dependency problems prevent configuration of
> > >> qubes-input-proxy-sender:
> > >> qubes-input-proxy-sender depends on qubes-core-agent (>= 3.0.25);
> > >> however:
> > >> Package qubes-core-agent is not configured yet.
> > >>
> > >
> > > My build finally finished running; got the same fatal error you did.
> > 
> > Might be some kind of interaction between
> > https://github.com/QubesOS/qubes-core-agent-linux/pull/81/commits/41f568766f36e7f7588c14490196c906e57a2c22
> > (merged 4 days ago) and
> > https://github.com/QubesOS/qubes-core-agent-linux/commit/00e846bbbe581aceeeaf4a8369748d4ff450b1b0.
> > 
> > Want to open an issue on it?
> 
> Yes I think so or at least I will post it over on devel.  Those update I 
> think are likely the root of it.  Maybe something small but the errors seem 
> to fit.
> 
> I will post it over on dev and git.

Issue opened: Qube 3.2 iso build error 'linux-template-builder' 
Stretch+Standard #3596 https://github.com/QubesOS/qubes-issues/issues/3596

-- 
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/664d27ff-19d1-494d-8546-29eda35597c4%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[qubes-users] Re: "Qubes Air: Generalizing the Qubes Architecture" by Joanna Rutkowska

[Tim W]

On Tuesday, January 23, 2018 at 11:30:08 PM UTC-5, Syd Brisby wrote:
> some considerations:
> 
> * Raspberry Pi, beagleboard, USB armory, etc are very low-powered devices (in 
> both CPU & RAM). So running Qubes software on them at a productive speed will 
> be a challenge.
> 
> * You're saying that laptop hardware specs are a problem for users. But 
> remember we had the problem of wireless modules still broadcasting after 
> being turned "off". So we needed laptops with wireless hardware switches to 
> be more certain that we couldn't be hacked. But now you are asking us to 
> again trust ordinary laptops and tablets that may not have hardware switches. 
> 
> * In reality, you are also changing from "deployment and virtualization" as a 
> single point of failure to "wireless" as the single point of failure. For 
> example, WPA2 has been declared insecure (hackable), with WPA3 being 
> necessary as a replacement. But, amazingly, WPA2 is still being "patched" by 
> manufacturers who think it's still acceptable - so how long will it take for 
> WPA3 to become ubiquitous?


Not sure how WIFI own encryption would be a single point failure, be it WPA2 or 
not, which I fully agree was a mess from the start.  

Is it not one a fair number of reasons we all use some combo of HTTPS VPN SSH 
TOR etc?   Would anyone here connect to the net without such a combo even just 
to surf regardless of the inherent black box network security?  Regardless of 
the connection medium be it radio waves via wifi bluetooth a network patch 
cable would it really matter?  

At my house I use a pi as a radius server so I am quite happy I got my patches 
for the wpa and not just sitting for 8 months waiting to get a unproven wpa3 
rolled out.  Not to mention that if wifi upgrades match android it will take 
5-7 years before unsupported code is no longer in wide spread use.  (I also use 
separate networks for things like TV IOT etc and data I consider higher value.)

Back on the subject of Qubes Air:

I could see connecting to a Raspberry cube or USB Armory Qube etc in a separate 
Zone via coms thru a VPN proxy VM qube connection.  I think this works to 
handle the above stated PDF scenario or as even a way as a further isolation 
from a badusb infected drive containing files.  I can also see it being a way 
to expand it into a decentrailized network of managed qubes with differing 
levels of security much like our current single PC Qubes OS presently offers.
 
Qubes has to be removed from any specific platform such as X86 or even the 
hypervisor unless we will always be at the mercy of their security practices 
etc..  Best not to be permanently married but rather a dating relationship. The 
key would be ensuring one zone could not compromise another zone if proper 
workflow security practices are enforced/followed.  Much how we handle data 
transfers between domains/qubes of different trust/security levels i.e red vs 
black etc... IMO once a level is chosen it would nice if rules could be 
enforced to prevent data flow rather than relying on the user to remember the 
proper flow.   IMO this becomes a priority with increased domains zones qubes 
etc.. That data can only flow in the proper direction without explicit work.

Its critical to understand that what the qubes OS is today would not be what 
would necessarily be running on these other zones but it also does not dismiss 
them from running it either.   You have to remove the idea of being what the 
entire QUBES OS we have today .

Anyways I liked the thought process and vision of the writeup.

-- 
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/6702b77f-10cc-4d8b-b76a-fb2fa486f16a%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[qubes-users] Re: Just installed AEM(Anti-Evil-Made)...see an error:(

[Tim W]

On Sunday, January 14, 2018 at 11:06:56 AM UTC-5, vel...@tutamail.com wrote:
> Managed to find what was causing the error and how to remove the error:
> 
> https://askubuntu.com/questions/778875/tpm-error-6-when-booting-thinkpad
> 
> https://bugzilla.redhat.com/show_bug.cgi?id=1413409
> 
> In my BIOS I went to Security -> Security Chip -> Security Chip set to 
> "Active"
> 
> However this brings up additional BIOS setting questions...
> 
> Any body have any thoughts on the best configuration for my default BIOS for 
> a Lenovo? Specifically related to the "Security Chip" settings?
> 
> Clear Security Chip?
> Intel TXT Feature?
> 
> I am not sure I am comfortable yet with changing my BIOS to Coreboot but love 
> the idea:)
> 
> My threat vector is more from a well funded malicious hacker(vs Intel or a 
> Government). Just trying to harden my PC the best I can...
> 
> Any thoughts or advice would be greatly appreciated.
> 
> Thanks,
> V

I have a t440p, what model do you have and processor version of tpm?  As you 
mention coreboot support I assume older model.

-- 
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/55173539-cbd6-4478-9153-061a42ef6490%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[qubes-users] Re: off topic - invite codes to 'riseup'

[Tim W]

I am sorry what is reason so many people want to get and use a riseup.net 
account outside political or some other social reason

They had their canary down for over a year because of gag order from the feds.

They have totally rewritten there canary statement since which was prior very 
clear and concise.  Now it looks to be heavily lawyered careful play on 
words...thus its vague using words that can having wide varying meaning.  what 
is omitted is any speech with the words warrant, gag order, NSL.  If they get 
any of those it will NOT of itself require them activating the canary protocol.

Here is their old Canary statement followed by the new one:

OLD:
riseup has not received any National Security Letters or FISA court orders, and 
we have not been subject to any gag order by a FISA court, or any other similar 
court of any government. Riseup has never placed any backdoors in our hardware 
or software and has not received any requests to do so. Riseup has never 
disclosed any user communications to any third party.


NEW:
Riseup positively confirms that the integrity of our system is sound. all our 
infrastructure is in our control, we have not been compromised or suffered a 
data breach, we have not disclosed any private encryption keys, and we have not 
been forced to modify our system to allow access or information leakage to a 
third party.


Unfortunately we cannot use common sense to read these but they must be read 
thru the eye of a laywer  I think you really see the effects of the rewritten 
statement. 

>From what I can tell the system is closed source.  They no longer offer any 
>form of encryption.  I must all be done on your email client.  There is no two 
>factor authentication.  The user name and password to get your into your 
>mailbox from what I can see maybe moot as there is no info on any use of 
>encryption outside users manually or thru a client using gpg.  If that is 
>correct then any mail not gpg encrypted is sitting in the mailbox in 
>cleartext.  Unless there is something like AES 256 protecting the mailbox via 
>your password but then that means thru the recovery passcode system they very 
>well can get back into your mailbox even with lost credentials and no reset 
>alternate email address.

For a person that plans to gpg encrypt all their emails what does this offer 
anyone over the other free email accounts.  Sure your contacts are not mined to 
hell and back but in terms of email content I see no difference and actually 
lower login security.

I was looking at the thread and it looks like around 40 people requested 
referral codes on this thread while the canary was expired.  One person even 
mentioned it and it went uncommented on.

Compare this to say protonmail its not even remotely close.  As both can be had 
for free and without all the need for referrals as its targeted toward 
liberal/social/anticapital political change groups not sure the point?  Elitism?

I honestly was surprised so many people on this list asking for it and where 
unphase by the fact the canary was expired and it was known they were under a 
gag order.  We make a big deal about a close source binary blob for a driver or 
firmware to a nic or gpu yet a closed source email provider system with a 
triggered canary and no one misses a beat?  I know the thread was off topic and 
has been running for years and why I never even read it till now for no other 
reason than I was wasting time but wow I am surprised.

-- 
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/9edf4fe4-2233-4ebd-9ea0-5b58fd728107%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [qubes-users] USB VM based on fedora-26 doesn't pass block devices

[Tim W]

On Friday, February 23, 2018 at 11:32:17 AM UTC-5, Kelly Dean wrote:
> awokd writes:
> > I wonder if this might be related to a recent patch in testing. Are both
> > your dom0 and templates on the same repository (current vs. testing) and
> > updated? A recent patch also required a reboot once both were updated.
> 
> Both on current, and both updated, and rebooted since last update.
> 
> Anyway, problem solved. I plugged the USB device into a different port, and 
> it worked (I got xvdi in the appVM). Then I detached and moved it back to the 
> port where I was having the problem, and this time it worked there too. 
> Aargh, heisenbug.


That almost sounds like a bug with the usb controller reset device or something 
to that effect.  I assume both usb ports are on the same controller.

-- 
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/1d14c9e1-cd69-4612-8577-061fe98ebf4c%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [qubes-users] Re: FYI: Kernel Hardening; a discussion (2018)

[Tim W]

On Sunday, March 11, 2018 at 8:11:57 PM UTC-4, awokd wrote:
> On Sun, March 11, 2018 5:49 pm, sevas wrote:
> > I did not mean to go so far south with the above statements. So heres my
> > additions for alternatives...
> >
> > CopperheadOS is doing a project still early in the making on reawakening
> > the open source kernel hardening. The GitHub page can be found here:
> > https://github.com/copperhead/linux-hardened/issues
> >
> >
> > ...which are limited.
> 
> I agree, it's disappointing grsecurity couldn't figure out a better way to
> handle that.
> 
> You might find this interesting, though:
> http://roscidus.com/blog/blog/2016/01/01/a-unikernel-firewall-for-qubesos/

Yeh I recall when it was all coming to a head over on their forum.   They tried 
IIRC legal action and pressure and costs were going to be debilitating thus I 
think that  is why they did what they did.  In fact I think in the end all they 
were looking for was recognition it was their code being used.  It was some 
time ago and I might not be recollecting it all.  But it was a big deal.


I really like the guys that make up copperhead.  They also did what they had to 
keep the doors open and viable for their android os version.  I paid the fee 
for the pixel to have them load to give my support to them.  Soon they should 
have pixel 2 all done and I will pay them again to have it on a pixel 2.  They 
strike a great balance for me between secure and usable.  They do good work IMO.

Cheers,

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/ff804a13-9b03-49a6-8d0f-e64966f6ffa6%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[qubes-users] Re: trouble with qubes-builder

[Tim W]

On Saturday, March 10, 2018 at 6:01:25 PM UTC-5, Tim W wrote:
> When I try to build anything with qubes-builder I keep getting an error when 
> its verifying tags.  Specifically this error below:
> 
> -> Updating sources for builder...
>│  
> │ --> Fetching from https://github.com/QubesOS/qubes-builder.git 
> master... │  
> │ --> Verifying tags...   
>  │  
> │ No valid signed tag found!  
>  │  
> │ ---> One of invalid tag:
>  │  
> │ object 9674c1991deef45b1a1b1c71fddfab14ba50dccf 
>  │  
> │ type commit 
>  │  
> │ tag mm_9674c199 
>  │  
> │ tagger Marek Marczykowski-Górecki 
> <marma...@invisiblethingslab.com> 1520035393 +0100
>  │  
> │ 
>  │  
> │ Tag for commit 9674c1991deef45b1a1b1c71fddfab14ba50dccf 
>  │  
> │ Makefile:194: recipe for target 'builder.get-sources' failed 
> 
> 
> None of this happened until Marek posted: 
> Announcement/warning: verification of git tag signatures in qubes-builder
> https://groups.google.com/forum/#!topic/qubes-devel/UyjsvvPzApI 
> 
> I first followed the directions to verify the sigs but after the error.  I 
> deleted qubes-builder and all the gpg sig keys.  Redownloaded the keys  and 
> installed qubes-builder and copied the keys over to it.
> 
> Now everytime I run any build when it gets-sources I get this error.  If I 
> continue to picking templates now the whonix template options are gone.
> 
> What is the reason for the missing tag? 
> 
> I am running this from a FC23 template.  It has worked fine for months 
> building 3.2 4.0 ISO as well as a number of templates.  This only happened 
> recently.
> 
> Marek commented but I do not really understand his comment as I followed the 
> directions in the thread and it all showed correctly.
> 
> Cheers,
> 
> Tim

Wow no one?

Can anyone check and see if they try to use qubes-builder after downloading all 
the sign keys.

-- 
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/1006aacc-c4bf-4d16-95c0-c5a125ae1f6f%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[qubes-users] Re: off topic - invite codes to 'riseup'

[Tim W]

On Saturday, March 10, 2018 at 9:38:38 AM UTC-5, little help wrote:
> On Wednesday, March 7, 2018 at 8:11:25 PM UTC+1, Tim W wrote:
> > I am sorry what is reason so many people want to get and use a riseup.net 
> > account outside political or some other social reason
> > 
> > They had their canary down for over a year because of gag order from the 
> > feds.
> > 
> > They have totally rewritten there canary statement since which was prior 
> > very clear and concise.  Now it looks to be heavily lawyered careful play 
> > on words...thus its vague using words that can having wide varying meaning. 
> >  what is omitted is any speech with the words warrant, gag order, NSL.  If 
> > they get any of those it will NOT of itself require them activating the 
> > canary protocol.
> > 
> > Here is their old Canary statement followed by the new one:
> > 
> > OLD:
> > riseup has not received any National Security Letters or FISA court orders, 
> > and we have not been subject to any gag order by a FISA court, or any other 
> > similar court of any government. Riseup has never placed any backdoors in 
> > our hardware or software and has not received any requests to do so. Riseup 
> > has never disclosed any user communications to any third party.
> > 
> > 
> > NEW:
> > Riseup positively confirms that the integrity of our system is sound. all 
> > our infrastructure is in our control, we have not been compromised or 
> > suffered a data breach, we have not disclosed any private encryption keys, 
> > and we have not been forced to modify our system to allow access or 
> > information leakage to a third party.
> > 
> > 
> > Unfortunately we cannot use common sense to read these but they must be 
> > read thru the eye of a laywer  I think you really see the effects of the 
> > rewritten statement. 
> > 
> > From what I can tell the system is closed source.  They no longer offer any 
> > form of encryption.  I must all be done on your email client.  There is no 
> > two factor authentication.  The user name and password to get your into 
> > your mailbox from what I can see maybe moot as there is no info on any use 
> > of encryption outside users manually or thru a client using gpg.  If that 
> > is correct then any mail not gpg encrypted is sitting in the mailbox in 
> > cleartext.  Unless there is something like AES 256 protecting the mailbox 
> > via your password but then that means thru the recovery passcode system 
> > they very well can get back into your mailbox even with lost credentials 
> > and no reset alternate email address.
> > 
> > For a person that plans to gpg encrypt all their emails what does this 
> > offer anyone over the other free email accounts.  Sure your contacts are 
> > not mined to hell and back but in terms of email content I see no 
> > difference and actually lower login security.
> > 
> > I was looking at the thread and it looks like around 40 people requested 
> > referral codes on this thread while the canary was expired.  One person 
> > even mentioned it and it went uncommented on.
> > 
> > Compare this to say protonmail its not even remotely close.  As both can be 
> > had for free and without all the need for referrals as its targeted toward 
> > liberal/social/anticapital political change groups not sure the point?  
> > Elitism?
> > 
> > I honestly was surprised so many people on this list asking for it and 
> > where unphase by the fact the canary was expired and it was known they were 
> > under a gag order.  We make a big deal about a close source binary blob for 
> > a driver or firmware to a nic or gpu yet a closed source email provider 
> > system with a triggered canary and no one misses a beat?  I know the thread 
> > was off topic and has been running for years and why I never even read it 
> > till now for no other reason than I was wasting time but wow I am surprised.
> 
> 
> 
> Yeah your concerns are legitimate.
> I guess they changed canary to make it more usable. Old one was a bit awkward 
> since due to warrant they were not able to update it or comment anything 
> about it.
> New one doesn't cover subpoenas and gag orders, but only covers 
> infrastructure they control and are always free to comment on.
> So new canary is not as reassuring as old one, but new one will not cause 
> this 6 months old radio silence when users didn't know what is going on.
> 
> Btw old gag order and investigation was because of some cryto blackmailing. I 
> think I found this somewhere on riseup canary pages.
> 
> You are right there is no

[qubes-users] trouble with qubes-builder

[Tim W]

When I try to build anything with qubes-builder I keep getting an error when 
its verifying tags.  Specifically this error below:

-> Updating sources for builder...  
 │  
│ --> Fetching from https://github.com/QubesOS/qubes-builder.git 
master... │  
│ --> Verifying tags... 
   │  
│ No valid signed tag found!
   │  
│ ---> One of invalid tag:  
   │  
│ object 9674c1991deef45b1a1b1c71fddfab14ba50dccf   
   │  
│ type commit   
   │  
│ tag mm_9674c199   
   │  
│ tagger Marek Marczykowski-Górecki 
 1520035393 +0100  
   │  
│   
   │  
│ Tag for commit 9674c1991deef45b1a1b1c71fddfab14ba50dccf   
   │  
│ Makefile:194: recipe for target 'builder.get-sources' failed 


None of this happened until Marek posted: 
Announcement/warning: verification of git tag signatures in qubes-builder
https://groups.google.com/forum/#!topic/qubes-devel/UyjsvvPzApI 

I first followed the directions to verify the sigs but after the error.  I 
deleted qubes-builder and all the gpg sig keys.  Redownloaded the keys  and 
installed qubes-builder and copied the keys over to it.

Now everytime I run any build when it gets-sources I get this error.  If I 
continue to picking templates now the whonix template options are gone.

What is the reason for the missing tag? 

I am running this from a FC23 template.  It has worked fine for months building 
3.2 4.0 ISO as well as a number of templates.  This only happened recently.

Marek commented but I do not really understand his comment as I followed the 
directions in the thread and it all showed correctly.

Cheers,

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/ca7e14bd-0e10-4396-bc36-315bb0d7ac22%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[qubes-users] Re: I broke Qubes with template reinstall...

[Tim W]

On Tuesday, March 6, 2018 at 1:53:37 AM UTC-5, sevas wrote:
> Reference:
> https://groups.google.com/forum/#!topic/qubes-users/5eJF__5UBAc
> 
> Apparently many people suffer from this problem. 
> After reinstalling the a few dire programs, everything seems to be working.
> Only problem is that the dom0 applications menu is gone. 
> Possible solution here:
> https://groups.google.com/forum/#!topic/qubes-users/lsED7b1qVjw
> 
> Im not messing with it. 
> I reinstalled.
> 
> Qubes Installation media does not (and did not previously) like partitions 
> with things on them. A quik trip over to the bash prompt and a little fdisk 
> and mkfs.ext4 and were right as rain!
> 
> reinstalling templates seem very unstable... Im not doing that .ever. again.


Yes I have always wiped all partitions and do a secure overwrite of all space.  
Sorry forgot about it when I mentioned doing a full reinstall.  I also only 
bkup data not the actual templates for the same issues and possible problems.

-- 
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/0886392b-a602-4c5a-9223-4f81b7fb2694%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[qubes-users] Qubes 4 and coreboot

[Tim W]

If your having iasues installing via petitboot here is a link to ibms specific 
instructions for petitboot and fedora redhat as well

https://www.ibm.com/support/knowledgecenter/en/linuxonibm/liabw/liabwinstallusb.htm

-- 
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/64a1a8e6-3433-4c9b-b29a-78ed664562c6%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [qubes-users] Dom0 connectivity for maintenance

[Tim W]

Day use for basic tasks sure mission critical no way.  IMO all one has to do is 
look at the hundreds of posts about issues not to mention if it was ready or 
close to it we would not be getting a 4.0 release canidate 5.  4.0 was such a 
change IMO its expected to have the need for this extra smoothing out of the 
code.

I guess its also perspective. Some people mission critcal can mean emails to 
there grandma others school work other where peoples lives and well being are 
on the line.

-- 
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/7f4bfd32-9a8a-4e83-a382-14e57bf2ec54%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [qubes-users] Re: non qubes

[Tim W]

On Saturday, March 3, 2018 at 6:33:27 AM UTC-5, awokd wrote:
> On Thu, March 1, 2018 11:13 am, Yuraeitha wrote:
> > On Thursday, March 1, 2018 at 9:30:52 AM UTC+1, jer...@disroot.org wrote:
> >
> >> where do i find support for security, privacy? (some place where i can
> >> post with anonimity too, reddit privacy requires java script i think,
> >> doesn't it compromise anonimity? also i would like to ask how things
> >> are recommended in doing, like a guide, etc...
> >>
> >> for example i need to know if enabling java script to watch youtube in
> >> tor will compromise anonimity or anything like that, or enabling java
> >> script in other websites, if it's a risk.. and how i should tell where
> >> i can enable java script, etc.. also if it's recommended to buy stuff
> >> through tor, and how, etc and what its benefits, etc...
> 
> General usage questions about Tor might be best asked over on the
> tor-users mailing list. Enabling Javascript anywhere is a risk because it
> opens up attack vectors to your computer, but by itself it will not
> automatically compromise anonymity. Someone would have to be using an
> exploit delivered over Javascript to do that. This is pretty unlikely in
> the case of large sites such as Youtube or Reddit, unless state agencies
> are targeting you specifically (which Tor makes more difficult).
> 
> Qubes is designed to contain exploits to a single VM. If you use it with a
> disposable VM for browsing, even if you do get compromised in a browsing
> session such as by a Javascript virus in Google ads on Youtube, closing
> that Tor Browser and opening a new one will result in it using a fresh,
> non-compromised disposable VM.
> 
> Buying items through Tor means using your real identity through Tor. Some
> people use Tor for everything including banking. Some use Tor for all
> browsing except anything involving their real identity. Others just use
> Tor occasionally for some sites. Try searching tor-users mailing list for
> questions similar to yours; you'll need to develop your own answer.

That is how 99.9% of those caught using tor are found.  Its from bad opsec not 
actually breaking of tor itself.Tech even the way silk road was brought 
down was via a spoof more than 100% of breaking tor.  but like anything layers. 
 Whats great about qubes is it helps in numerous ways from being resistant to 
the spread of malware its easy integration oh whonix.  It ability to string 
numerous network tunneling chains together to creating multiple layers if done 
correctly have the effect of indecent cells working to a common goal with only 
the end user knowing all parts.  Qubes is but one part but its configuration 
allows for numerous ways and layer for security and or if done with proper 
opsec anonymity

-- 
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/5b7e0c16-0c5a-4c6e-a357-54d9a44800bf%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

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

[Tim W]

On Friday, March 2, 2018 at 10:14:51 PM UTC-5, Tim W wrote:
> On Friday, March 2, 2018 at 4:05:30 AM UTC-5, Unman wrote:
> > On Fri, Mar 02, 2018 at 12:41:29AM -0800, Tim W wrote:
> > > On Tuesday, February 27, 2018 at 2:37:46 AM UTC-5, Frédéric Pierret 
> > > (fepitre) wrote:
> > > > Le mardi 27 février 2018 00:30:10 UTC+1, Tim W a écrit :
> > > > > Great that was failing basically on all non standard templates i.e. 
> > > > > not fedora, debain, or whonix.   They would all fail but it seems 
> > > > > each had issues ubuntu, centos, arch.  Seems they are each getting 
> > > > > fixed for 3.2 and getting updated for 4.0 now.  I was just testing to 
> > > > > ensure things were still working for building as I know many prefer 
> > > > > to build their own iso and templates vs binary.  I am one.  Figured 
> > > > > if docs had to be updated I would do that but it seems at most just a 
> > > > > tweak or two in docs is all thats needed.
> > > > 
> > > > Indeed, it was just an adjustment with respect to the rpm spec of the 
> > > > conflicting package. CentOS is shipping a file in their own dconf but 
> > > > not Fedora. Recently a file /etc/dconf/profile/user has been used and 
> > > > provided by Qubes and that is why there was a recent conflict. The 
> > > > template for R4.0 is on the road! I finished last week to do all the 
> > > > necessary and Marek is currently implementing it.
> > > >  
> > > > > Thanks again for you and Marek getting it working
> > > > 
> > > > You're welcome.
> > >  
> > > Just tried to build the standard template only under 3.2 and got this 
> > > conflict
> > > 
> > > Transaction check error:
> > >   file /etc/dconf/profile/user from install of 
> > > qubes-core-vm-3.2.25-1.el7.centos.x86_64 conflicts with file from package 
> > > dconf-0.26.0-2.el7.x86_64
> > > 
> > > It fails on $make template
> > > 
> > 
> > It's the same conflict - I guess you need to wait for the change to be
> > merged to 3.2
> 
> Yes sorry about that it was very late and I was a bit punchy.

Since Marek updated the qubes builder to address the security bulletin issue 
the tag for centos is no longer valid so it fails the update after choosing the 
centos template with a invalid / no valid tag found error but does proceed to 
allow choosing of the templates to build.

-- 
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/76b8b492-9410-4850-96cf-8acf48da95d9%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

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

[Tim W]

On Sunday, March 4, 2018 at 12:45:21 AM UTC-5, Tim W wrote:
> On Friday, March 2, 2018 at 10:14:51 PM UTC-5, Tim W wrote:
> > On Friday, March 2, 2018 at 4:05:30 AM UTC-5, Unman wrote:
> > > On Fri, Mar 02, 2018 at 12:41:29AM -0800, Tim W wrote:
> > > > On Tuesday, February 27, 2018 at 2:37:46 AM UTC-5, Frédéric Pierret 
> > > > (fepitre) wrote:
> > > > > Le mardi 27 février 2018 00:30:10 UTC+1, Tim W a écrit :
> > > > > > Great that was failing basically on all non standard templates i.e. 
> > > > > > not fedora, debain, or whonix.   They would all fail but it seems 
> > > > > > each had issues ubuntu, centos, arch.  Seems they are each getting 
> > > > > > fixed for 3.2 and getting updated for 4.0 now.  I was just testing 
> > > > > > to ensure things were still working for building as I know many 
> > > > > > prefer to build their own iso and templates vs binary.  I am one.  
> > > > > > Figured if docs had to be updated I would do that but it seems at 
> > > > > > most just a tweak or two in docs is all thats needed.
> > > > > 
> > > > > Indeed, it was just an adjustment with respect to the rpm spec of the 
> > > > > conflicting package. CentOS is shipping a file in their own dconf but 
> > > > > not Fedora. Recently a file /etc/dconf/profile/user has been used and 
> > > > > provided by Qubes and that is why there was a recent conflict. The 
> > > > > template for R4.0 is on the road! I finished last week to do all the 
> > > > > necessary and Marek is currently implementing it.
> > > > >  
> > > > > > Thanks again for you and Marek getting it working
> > > > > 
> > > > > You're welcome.
> > > >  
> > > > Just tried to build the standard template only under 3.2 and got this 
> > > > conflict
> > > > 
> > > > Transaction check error:
> > > >   file /etc/dconf/profile/user from install of 
> > > > qubes-core-vm-3.2.25-1.el7.centos.x86_64 conflicts with file from 
> > > > package dconf-0.26.0-2.el7.x86_64
> > > > 
> > > > It fails on $make template
> > > > 
> > > 
> > > It's the same conflict - I guess you need to wait for the change to be
> > > merged to 3.2
> > 
> > Yes sorry about that it was very late and I was a bit punchy.
> 
> Since Marek updated the qubes builder to address the security bulletin issue 
> the tag for centos is no longer valid so it fails the update after choosing 
> the centos template with a invalid / no valid tag found error but does 
> proceed to allow choosing of the templates to build.



[user@Build-Qubes qubes-builder]$ make get-sources
-> Updating sources for builder-centos...
--> Fetching from https://github.com/QubesOS/qubes-builder-centos.git master...
--> Verifying tags...
No valid signed tag found!
---> One of invalid tag:
object cfc7d315cfdfe493a86f103a0825ba630339ab8f
type commit
tag mm_cfc7d315
tagger Marek Marczykowski-Górecki <marma...@invisiblethingslab.com> 1519612572 
+0100

Tag for commit cfc7d315cfdfe493a86f103a0825ba630339ab8f
gpg: WARNING: unsafe permissions on homedir 
`/home/user/qubes-builder/keyrings/git'
gpg: Signature made Sun 25 Feb 2018 09:36:12 PM EST using RSA key ID 42CFA724
gpg: Good signature from "Marek Marczykowski-Górecki (Qubes OS signing key) 
<marma...@invisiblethingslab.com>"
Makefile:190: recipe for target 'builder-centos.get-sources' failed
make: *** [builder-centos.get-sources] Error 1

-- 
You received this message because you are subscribed to the Google Groups 
"qubes-users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to qubes-users+unsubscr...@googlegroups.com.
To 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/f96c34a7-c302-4e9e-be59-7b1ee988437e%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[qubes-users] Re: High spec laptop for Qubes OS

[Tim W]

Everyone knows those issues on this board and its understood.  Point being he 
asked for present day high end laptop but at the same time I will agree with 
you that for most basic use models its not so much the processor as it is ram 
amount but one thing for sure is you can not recommend a PC that one is not a 
laptop and two has no xen or qubes support i.e talon/powerpc.

I think its rather moot talking about intel backdoors when its 100% plausible 
that countless firmwares are backdoored.  Its been mentioned numerous times by 
Joanna Marek and others that at some point at this current point in consumer 
computing ayou must accept trust.  Whatever that point is may be different for 
different people but unless you are going to make a computer from silicon up 
and every line of code to include a compiler etc you must trust at some level.  
Thus the whole idea of picking and choosing which of the possible violation is 
unacceptable is rather moot

-- 
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/2baa7894-839f-4bed-89d8-fd427eb0152f%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

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

[Tim W]

On Friday, March 2, 2018 at 4:05:30 AM UTC-5, Unman wrote:
> On Fri, Mar 02, 2018 at 12:41:29AM -0800, Tim W wrote:
> > On Tuesday, February 27, 2018 at 2:37:46 AM UTC-5, Frédéric Pierret 
> > (fepitre) wrote:
> > > Le mardi 27 février 2018 00:30:10 UTC+1, Tim W a écrit :
> > > > Great that was failing basically on all non standard templates i.e. not 
> > > > fedora, debain, or whonix.   They would all fail but it seems each had 
> > > > issues ubuntu, centos, arch.  Seems they are each getting fixed for 3.2 
> > > > and getting updated for 4.0 now.  I was just testing to ensure things 
> > > > were still working for building as I know many prefer to build their 
> > > > own iso and templates vs binary.  I am one.  Figured if docs had to be 
> > > > updated I would do that but it seems at most just a tweak or two in 
> > > > docs is all thats needed.
> > > 
> > > Indeed, it was just an adjustment with respect to the rpm spec of the 
> > > conflicting package. CentOS is shipping a file in their own dconf but not 
> > > Fedora. Recently a file /etc/dconf/profile/user has been used and 
> > > provided by Qubes and that is why there was a recent conflict. The 
> > > template for R4.0 is on the road! I finished last week to do all the 
> > > necessary and Marek is currently implementing it.
> > >  
> > > > Thanks again for you and Marek getting it working
> > > 
> > > You're welcome.
> >  
> > Just tried to build the standard template only under 3.2 and got this 
> > conflict
> > 
> > Transaction check error:
> >   file /etc/dconf/profile/user from install of 
> > qubes-core-vm-3.2.25-1.el7.centos.x86_64 conflicts with file from package 
> > dconf-0.26.0-2.el7.x86_64
> > 
> > It fails on $make template
> > 
> 
> It's the same conflict - I guess you need to wait for the change to be
> merged to 3.2

Yes sorry about that it was very late and I was a bit punchy.

-- 
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/6906ac1c-4e53-4d0b-81ac-f33ef108bab3%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[qubes-users] Re: Qubes OS Stable Release 3.2. (Cant up-date template to fedora-26 or fedora-27)

[Tim W]

Inhave gotten errors such as those building qubes iso and templates.  I now 
break up the components and bud them in small in order groups so I can start 
where it fails vs running the whole script build.

I would try again and as was said restart the nework vm chain or full 
powercycle the machine.  It really sucks when that happens on a six hour custom 
qubes iso build and you bogger it and have to start over.  Live and learn I 
guess lol

-- 
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/90acf871-d748-48f1-aac3-e1d797413a3e%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[qubes-users] Re: Will there be a gentoo template in the plans?

[Tim W]

If you get it working I am happy 5o write up a hpw to doc for qubes doc.

-- 
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/6c089d3a-2cc6-45f6-8a9c-6e9ede65f658%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[qubes-users] Re: Will there be a gentoo template in the plans?

[Tim W]

I worked on this way back qubes 3.0 but never got it finished a bit of a bear 
compared to others given the nature of build vs install.  I greatly precer 
gentoo over arch but ended up usimg the later.  Still much happier if gentoo 
got working.  

-- 
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/a283fb4a-10ad-4654-bc2f-abc166eac780%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[qubes-users] Qubes 4.0 rc4 / Qubes backup doesn't find the directory

[Tim W]

On the last part you are saying even picking root of the removable it still 
fails same error?

-- 
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/3e1987e8-a9dd-4e31-a311-33baa1bfae35%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

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

[Tim W]

Great that was failing basically on all non standard templates i.e. not fedora, 
debain, or whonix.   They would all fail but it seems each had issues ubuntu, 
centos, arch.  Seems they are each getting fixed for 3.2 and getting updated 
for 4.0 now.  I was just testing to ensure things were still working for 
building as I know many prefer to build their own iso and templates vs binary.  
I am one.  Figured if docs had to be updated I would do that but it seems at 
most just a tweak or two in docs is all thats needed.

Thanks again for you and Marek getting it working

-- 
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/a3b5e411-0c29-446c-93a5-d11f587ac1a8%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [qubes-users] Qubes 4 and coreboot

[Tim W]

On Thursday, March 1, 2018 at 7:30:02 PM UTC-5, qube...@go-bailey.com wrote:
> Thanks all for the additional feedback about working payloads.
> 
> Tim, thanks. I used some similar guides to try some different configs 
> when I was attempting with petitboot. As best I could tell the issue 
> wasn't so much with fedora per se but with getting it to boot with 
> fedora and xen. I was able to get it to boot partially but never all the 
> way through.
> 
> Based on the comments in this thread though, am going to try SeaBIOS.

sounds good when in doubt go with whats proven to work.  Too bad as petitboot 
has nice features

-- 
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/73af89be-87c0-4f4c-b3ec-bcde73eb2925%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

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

[Tim W]

On Tuesday, February 27, 2018 at 2:37:46 AM UTC-5, Frédéric Pierret (fepitre) 
wrote:
> Le mardi 27 février 2018 00:30:10 UTC+1, Tim W a écrit :
> > Great that was failing basically on all non standard templates i.e. not 
> > fedora, debain, or whonix.   They would all fail but it seems each had 
> > issues ubuntu, centos, arch.  Seems they are each getting fixed for 3.2 and 
> > getting updated for 4.0 now.  I was just testing to ensure things were 
> > still working for building as I know many prefer to build their own iso and 
> > templates vs binary.  I am one.  Figured if docs had to be updated I would 
> > do that but it seems at most just a tweak or two in docs is all thats 
> > needed.
> 
> Indeed, it was just an adjustment with respect to the rpm spec of the 
> conflicting package. CentOS is shipping a file in their own dconf but not 
> Fedora. Recently a file /etc/dconf/profile/user has been used and provided by 
> Qubes and that is why there was a recent conflict. The template for R4.0 is 
> on the road! I finished last week to do all the necessary and Marek is 
> currently implementing it.
>  
> > Thanks again for you and Marek getting it working
> 
> You're welcome.
 
Just tried to build the standard template only under 3.2 and got this conflict

Transaction check error:
  file /etc/dconf/profile/user from install of 
qubes-core-vm-3.2.25-1.el7.centos.x86_64 conflicts with file from package 
dconf-0.26.0-2.el7.x86_64

It fails on $make 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/bc0793b9-8b9d-4e36-84a5-919e002edfcd%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[qubes-users] Re: Will there be a gentoo template in the plans?

[Tim W]

On Tuesday, February 27, 2018 at 2:47:37 AM UTC-5, Frédéric Pierret (fepitre) 
wrote:
> Le mardi 27 février 2018 00:23:32 UTC+1, Tim W a écrit :
> > If you get it working I am happy 5o write up a hpw to doc for qubes doc.
> 
> Thank you! Yesterday I was thinking about releasing a first pre-version of 
> the builder-gentoo I've made to eventually be helped. If I remember I was 
> ending on packaging linux-utils. So maybe I could ask to Andrew to open a 
> project on qubes-issues or something like it to track the progress.

That would be GREAT!!  Its one if not my favorite distro.  I also while I love 
the ease of management systemd has brought I do not like the virus like growth 
of it and bu buggy coding practices and nonunix mentaility.  OpenRC to me is 
better example of what systemd should be.

Anyways great to see this move forward and happy to help with testing and doc 
work.

-- 
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/0d2d24ea-c03e-4af6-82ff-f42717e3a461%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[qubes-users] Re: non qubes

[Tim W]

On Thursday, March 1, 2018 at 3:30:52 AM UTC-5, jer...@disroot.org wrote:
> where do i find support for security, privacy? (some place where i can post 
> with anonimity too, reddit privacy requires java script i think, doesn't it 
> compromise anonimity? also i would like to ask how things are recommended in 
> doing, like a guide, etc...
> 
> for example i need to know if enabling java script to watch youtube in tor 
> will compromise anonimity or anything like that, or enabling java script in 
> other websites, if it's a risk.. and how i should tell where i can enable 
> java script, etc.. also if it's recommended to buy stuff through tor, and 
> how, etc and what its benefits, etc...

Javascript itself will not reveal your IP over Tor ie break tor.  But 
javascriptt has always had security issues that could be used to run code that 
could itself reveal ip etc.  This is more an issue with emails and small or 
spoofed sites etc not a large offical site like youtube.  

Honestly I do not understand people using gmail etc if privacy is critical.  
Even using pgp for all text etc so much can be learned from your habits email 
accounts contacted time of use etc...  Its sad they own so much of the Internet 
data and portal activity these days such as youtube.  I wish this list was not 
hosted but its so hard to avoid the carrot when its a opensource project. 

Use tor to setup a protonmail etc if you need a webmail account.

-- 
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/3a89da4b-6393-4cbd-b1ea-e768d7c17b8c%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [qubes-users] High spec laptop for Qubes OS

[Tim W]

On Tuesday, February 27, 2018 at 8:36:02 PM UTC-5, Francesco wrote:
> On Sat, Feb 24, 2018 at 10:52 PM, tai...@gmx.com  wrote:
> I suggest a lenovo W520, as it supports coreboot with open source hw init and 
> me cleaner (which nerfs but does not disable ME - it is impossible to disable 
> ME, dell/purism are lying) you can also use an egpu for additional graphics 
> power and install an ivy bridge processor for better power figures.
> 
> 
> 
> I would also look in to the TALOS 2 (OpenPOWER9) which is a very high 
> performance owner controlled workstation with libre firmware for both the 
> board and BMC (even the microcode is owner controlled and has documentation 
> supplied, there is absolutely no hardware code signing enforcement).
> 
> POWER is now the worlds only owner controlled performance cpu arch due to 
> both intel and AMD adopting black box supervisor processors and hardware code 
> signing enforcement.
> 
> https://raptorcs.com
> 
> It also supports CAPI and PCI-e 4.0, which I imagine might interest you.
> 
> 
> 
> 
> 
> But does Talos 2 work with Xen? It seems it does not:
> https://www.google.com.br/url?sa=t=j==s=web=1=rja=8=0ahUKEwig_reIlsLZAhXK2VMKHRlvC6cQFggrMAA=https%3A%2F%2Fgroups.google.com%2Fd%2Fmsg%2Fqubes-users%2FbqRSuU3T6MA%2Fn9tFozKsAQAJ=AOvVaw2aUCCm88WSdcxkcCqWhZbe

No it does not yet it gets repeatedly mentioned to where it makes people think 
its viable option which it is not.  

The op wants a high end laptop which also eliminates all the old coreboot 
laptops.  as he wants a laptop it also removes the asusu amd server board 
desktop builds.  Best bet is lenovo thinkpad with the highest ram and processor 
combo and ssd drive/s.  It will likely give the best compatibility

-- 
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/49bbd781-7f01-4661-a339-dceb9f434d76%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [qubes-users] Re: High spec laptop for Qubes OS

[Tim W]

On Sunday, March 4, 2018 at 3:32:15 PM UTC-5, tai...@gmx.com wrote:
> On 03/02/2018 10:13 PM, Tim W wrote:
> 
> > Everyone knows those issues on this board and its understood.  Point being 
> > he asked for present day high end laptop but at the same time I will agree 
> > with you that for most basic use models its not so much the processor as it 
> > is ram amount but one thing for sure is you can not recommend a PC that one 
> > is not a laptop and two has no xen or qubes support i.e talon/powerpc.
> >
> > I think its rather moot talking about intel backdoors when its 100% 
> > plausible that countless firmwares are backdoored.
> Considering that the TALOS 2, KGPE-D16, KCMA-D8 and the G505S's 
> firmwares are open source and every component such as pci-e addon cards 
> that aren't are restricted by the IOMMU - again you give dangerous 
> advice and suggest that people focus on some vague theoretical backdoor 
> rather than what is a proven fact (that intel machines are owned by 
> intel, not you) and thus tell them they shouldn't even bother with security.
> 
> I mean by those standards why use qubes at all? it probably has 
> backdoors from all the worlds governments so you might as well just use 
> windows 10!
> > Its been mentioned numerous times by Joanna Marek and others that at some 
> > point at this current point in consumer computing ayou must accept trust.  
> > Whatever that point is may be different for different people but unless you 
> > are going to make a computer from silicon up and every line of code to 
> > include a compiler etc you must trust at some level.  Thus the whole idea 
> > of picking and choosing which of the possible violation is unacceptable is 
> > rather moot
> So what you are saying is that because someone could have theoretically 
> slipped some super clever backdoor in to an open source firmware it 
> doesn't matter at all and why not just get a closed source firmware 
> laptop with ME?
> 
> That is not at all what they are saying.
> 
> What exactly are your professional qualifications on this matter? Do you 
> own at least one computer with open source firmware? If you are so 
> concerned with your privacy why do you use gmail?

Wownfine I give up h you ha e read so much into my commemts that I never 
intnnded whatever.  Tell the guy that wants a high end laptop to buy a power pc 
or a talonto run qubes ofc it.  Or to use those ausu boards as that will make 
angreat laptop. Since every piiece of hardware you use om those syztems is 
100% opensource I guess that includes the harddrive firmware w.  As this op 
wants a laptop though please name a single open that meets the standards you 
speak of with no close sourced  firmware and drivers.  Becuase no LE agencies 
in the USA ha e ever used backdoor firmware on hardrives.

Actually do not bother as I am done distruptiong this ops threads with such off 
topic drivel.   

There are plenty of choices for high end laptops that have been suggested or 
can be found on the compatbility list.  

-- 
You received this message because you are subscribed to the Google Groups 
"qubes-users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to qubes-users+unsubscr...@googlegroups.com.
To 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/de4c0c57-6c09-43f1-ae99-8219ae2a0bed%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[qubes-users] Re: Install Android-x86 on HVM

[Tim W]

On Thursday, March 1, 2018 at 11:17:25 AM UTC-5, msg...@gmail.com wrote:
> On Thursday, March 1, 2018 at 7:50:44 PM UTC+7, Yuraeitha wrote:
> > On Thursday, March 1, 2018 at 11:11:44 AM UTC+1, msg...@gmail.com wrote:
> > > Hello,
> > > 
> > > I want to install Android-x86 on Qubes OS 4.0rc4 StandaloneVM (HVM), but 
> > > the Android installer can't recognize the VM drives.
> > > I can run the Android Live from the iso and it works.
> > > I've tried to install Android-x86 7.1-rc1/6.0-rc3/4.4-rc5 but they can't 
> > > recognize the VM drives.
> > > Based on some messages from mailing list/github issues, it was possible 
> > > to install Android-x86 on HVM in Qubes OS 3.2 (or pre 4.0rc4?) but I 
> > > can't do it in Qubes 4.0rc4.
> > > Maybe someone have some clues on how to make the Android-x86 installer 
> > > recognize VM drives?
> > 
> > Could it be because of the kernel is loaded in a similar way to how it for 
> > example prevents Windows to install? I'd guess any standalone shares this 
> > issue in Qubes 4 and not just Windows. Linux or not, if it tries to use its 
> > own kernel rather than the one provided by dom0, then it would probably not 
> > work. 
> > 
> > This should disable the VM's kernel, though I never used it my self, try 
> > adjust if the citation marks are different.
> > qvm-prefs android-vm-name kernel ''
> > 
> > I can confirm from personal experience that Android remix was possible to 
> > be installed during Qubes 3.2., though I didn't try on Qubes 4 yet. 
> > Generally it should work though, you probably just need to bypass some 
> > issues, like the kernel issue above, and perhaps you need to adjust the 
> > virt_mode too qvm-prefs android-vm-name virt_mode. Try change it to HVM if 
> > it isn't already. I'm not sure if the GUI VM Settings has been fixed for 
> > the Virt_mode, otherwise just use the dom0 terminal with above command to 
> > change it.
> 
> I've already set the kernel to '', virt_mode to HVM, disabled memory 
> balancing and set memory to 4GB, it didn't help.
> I've installed Windows 7/10 without any problems on this same Qubes OS 4.0rc4 
> but I can't install Android-x86 with the same config.

I do not think the mouse  behavior issue has ever been able to be addressed.  
It is mentioned in most of the android attempt threads.  There have been 
numerous requests for actual android auppprt but without fully functional mouse 
behavior it prevents proper use function.  As far as I know it has been an 
issue in ever successful install of android on qubes but I could be wrong.  

-- 
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/94e81362-c458-4b81-963a-194537efdb01%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[qubes-users] Re: I broke Qubes with template reinstall...

[Tim W]

On Monday, March 5, 2018 at 11:29:30 PM UTC-5, sevas wrote:
> dom0$ sudo qubes-dom0-update --action=reinstall qubes-template-debian-9
> 
> Now my dom0 menu is gone. No more terminal. No more Qubes Manager. No more... 
> anything... 
> 
> 
> I gave up immediately and thought I would reinstall Qubes. 
> 
> Well, that was a fail too. Qubes installer freezes when I click Continue on 
> the first page. 
> 
> Any suggestions??

As far as I know there is nothimg you could do inside qubes such as you have 
described that cwould also effect reinstalling qubes fresh.  After all you are 
booting from  Usb or dvd media.  My guess is maybe you changed something in 
system firmware/BIOS or maybe a step you had to do the first install but maybe 
forgot this time?

Just trying to throw ideas out there as nothing on the hd should  effect a 
install from external boot source.

Are you usimg the same install media and version i.e. you did not download a 
fresh QUBES OS ISO etc where possible updated changes could have been made 
etc.. vs your previous install.

When I do something that seems to screw up many subsys5ems etc I like you did 
prefer to just do a reinstall and restore data.  But prior to that I still try 
to fix the issue first to learn what I broke and how.  That is if time allows 
of course.  Then I wipe and install to be sure there is nothing left over from 
the issue that could cause phant9m issues later.  Mayne not necessary but a 
habit I can not shake after supporting numerous Microsoft shops for over 25 
yrs.  

-- 
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/8449ef4b-ad30-4dc8-bbca-eecf3a931775%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [qubes-users] Security questions (templates and kde)

[Tim W]

On Tuesday, March 6, 2018 at 12:23:10 AM UTC-5, Yuraeitha wrote:
> On Tuesday, March 6, 2018 at 5:24:50 AM UTC+1, sevas wrote:
> > Thank you both for this enlightening talk, and especially Yuraeitha for 
> > such a lengthy researched opinion!
> > 
> > We speak of stability. Stability and vulnerability go hand in hand, dont 
> > they?
> > 
> > I love the kde plasma desktop and I would like to have it. But it looks 
> > like a complicated GUI that probably is not as secure as something more 
> > simple. But again, the non-root GUI is not going to connect to the 
> > internet. 
> > 
> > My previous feelings were to use one template for internet access and one 
> > for background/desktop/personal use. But that may not be needed since 
> > applications available in a template are not necessarily used in the appVM. 
> > Is that correct or would there be some data leak?
> > 
> > XFCE is something I havent used in a long time, but I will surely look into 
> > my customization techniques before I make a big move.
> 
> About the stability going hand in hand with vulnerability, I view it the same 
> way too, though it's not always the case if it isn't possible to exploit it, 
> which also isn't always possible too.
> 
> Qubes once used KDE btw, you can find the discussion that made the change 
> from KDE to XFCE5 here https://github.com/QubesOS/qubes-issues/issues/2119
> Some of these issues I believe have changed though, what is perceived as 
> "ugly" was back then a bit of an unlucky controversial statement due to 
> different subjective opinions and it caused a bit of a stir in the KDE 
> community. But I believe KDE also corrected some of those issues since then? 
> 
> It's a good idea to keep your critical offline app's and data in an offline 
> VM btw, keep doing that. You can also find multiple of official Qubes 
> recommendations suggesting this offline AppVM move. For example the Split GPG 
> guide in the Qubes doc's recommend this approach in order to keep your GPG 
> keys more secure from being hacked. For example if only one application makes 
> an outgoing opening in the firewall in the AppVM, then data in that AppVM 
> might be opened to risk through exploits and attacks to that established 
> connection. I have about 15-17 AppVM's which I use, not including the ones I 
> don't use or templates, and I'm probably a light AppVM user compared to the 
> more extreme ones. If it seems overwhelming though, try start with a set 
> smaller number of VM's, then as you get used to it, try expand with a couple 
> of VM's at a time. Think about what it adds to security or practical 
> use-cases, and keep reviewing your VM layout :)
> 
> I believe there should be no issue switching between XFCE4 and KDE though, 
> since the guide to KDE doesn't mention deleting XFCE4, just disabling it (at 
> least it didn't at the time I read it). So presumably you should be able to 
> switch between them with 2-3 commands in the tty terminal. You mihgt want to 
> double-check that though, for example can you keep switching between them 
> multiple of times without causing any harm to the system?

Correct.  I have had both on and functioned fine.

For secuirty I see little difference other than maybe the amount of code.  The 
more code ,all things being equal, the more possible holes errors surface area 
to attack. 
  

-- 
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/5a9babef-ccf3-44d9-89f5-4b4b3640e745%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [qubes-users] Re: non qubes

[Tim W]

On Sunday, March 4, 2018 at 1:58:44 PM UTC-5, awokd wrote:
> On Sun, March 4, 2018 5:34 am, Tim W wrote:
> > On Saturday, March 3, 2018 at 6:33:27 AM UTC-5, awokd wrote:
> 
> >> Buying items through Tor means using your real identity through Tor.
> >> Some
> >> people use Tor for everything including banking. Some use Tor for all
> >> browsing except anything involving their real identity. Others just use
> >>  Tor occasionally for some sites. Try searching tor-users mailing list
> >> for questions similar to yours; you'll need to develop your own answer.
> >
> > That is how 99.9% of those caught using tor are found.  Its from bad
> > opsec not actually breaking of tor itself.Tech even the way silk road
> > was brought down was via a spoof more than 100% of breaking tor.  but
> > like anything layers.  Whats great about qubes is it helps in numerous
> > ways from being resistant to the spread of malware its easy integration
> > oh whonix.  It ability to string numerous network tunneling chains
> > together to creating multiple layers if done correctly have the effect of
> > indecent cells working to a common goal with only the end user knowing
> > all parts.  Qubes is but one part but its configuration allows for
> > numerous ways and layer for security and or if done with proper opsec
> > anonymity
> 
> Agree with what you say except I want to redefine "caught" to "security
> failure". In the case of someone using Tor in conjunction with their real
> identity, for example, they aren't worried about the site or any third
> party trackers knowing WHO they are during that particular session. Their
> primary concern (aka a security failure for them) might be revealing their
> location by their real IP (or in the third party trackers case,
> link-ability across sessions/other sites by super cookies etc.). The trade
> off, though, is their traffic may get routed through network path that is
> less trusted than user -> ISP -> ISP -> site; would be user -> Tor ->
> random exit node -> random exit node's ISP -> ISP -> site. That's why
> there is no comprehensive, simple answer on the "right" way to use Tor. It
> varies by what you are trying to accomplish. See
> https://www.torproject.org/docs/faq.html.en#WhatProtectionsDoesTorProvide
> , or https://www.torproject.org/docs/documentation.html.en for more
> details and support options.

I could not agree more.  Also very well put and easy to understand example.  
You always have to define the use and what you are protecting and from who.  No 
one way for everything.

-- 
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/48bb8093-3fce-4f21-a3a3-2d60decdfb30%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[qubes-users] Re: btrfs for template/appvm

[Tim W]

Looks to me like it has support in appvms

On Friday, December 11, 2020 at 7:36:59 PM UTC-5 keyandthegate wrote:

> I want to use btrfs for the snapshots feature in my appvms.
>
> I know Qubes supports btrfs for dom0:
> https://github.com/QubesOS/qubes-issues/issues/2340
>
> Does Qubes support using btrfs in individual appvms?
>
> If not is there some other way I can get snapshots? It would make me less 
> afraid to make a mistake while using my computer.
>

-- 
You received this message because you are subscribed to the Google Groups 
"qubes-users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to qubes-users+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/qubes-users/cc8d2c66-12d2-4327-b21b-4d8241fc5baen%40googlegroups.com.

[qubes-users] Re: btrfs for template/appvm

[Tim W]

Looks to me that is has support for functioning in appvms.,  But I can not 
test currently
On Friday, December 11, 2020 at 7:36:59 PM UTC-5 keyandthegate wrote:

> I want to use btrfs for the snapshots feature in my appvms.
>
> I know Qubes supports btrfs for dom0:
> https://github.com/QubesOS/qubes-issues/issues/2340
>
> Does Qubes support using btrfs in individual appvms?
>
> If not is there some other way I can get snapshots? It would make me less 
> afraid to make a mistake while using my computer.
>

-- 
You received this message because you are subscribed to the Google Groups 
"qubes-users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to qubes-users+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/qubes-users/c8a64300-1bb7-4ca7-bb0f-abfd8d89edb1n%40googlegroups.com.