How do I get Qubes 4.0 pre-release/dev build?

[bent...@cloudctrl.nl]

Hi,

I've been using Qubes-OS since R2, and I would like to start using the development build so I can try and do some testing for some unikernel and mirage-based security stuff I want to implement.

Can someone tell me where I can get the files? Any tips or hints when it comes to running the latest build?

Hope someon can help me get it.

P.S.
How long before the first rc will be released? This shouldnt be much longer right?

[Jean-Philippe Ouellet]

On Wed, Nov 30, 2016 at 11:49 AM, <bent...@cloudctrl.nl> wrote:
> Can someone tell me where I can get the files? Any tips or hints when it comes to running the latest build?

I am not aware of any publicly-available full "development builds",
however qubes-builder[1] makes it very easy to build them yourself..

[1]: https://www.qubes-os.org/doc/qubes-builder/

[bent...@cloudctrl.nl]

Should I just download memmek's qubes-build? Or the normal one aswell? Or just the normal one?

Could someone give me a detailed explanation how I should build the most recent R4.0 iso, with the most up to date dom0 and vm builds?

R4 Will be fedora-23 based for dom0 right? Will I be able to use this build for day to day working in its current state? Or is it still too early?

I would also like to know what choices have been made regarding pvhvm or hvmlite as the main virtualization architecture?

Is the fedora build the most complete? Or would debian have any benefits over fedora?

What parameters should I pick? Version r4.0.0, with dev. Testing or something ? What about unstable vs security-testing?

Hope someone can explain how I can build myself a good r4.0 iso.

[Marek Marczykowski-Górecki]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256

On Thu, Dec 01, 2016 at 02:54:03AM -0800, bent...@cloudctrl.nl wrote:
> Should I just download memmek's qubes-build? Or the normal one aswell? Or just the normal one?
>
> Could someone give me a detailed explanation how I should build the most recent R4.0 iso, with the most up to date dom0 and vm builds?
>
> R4 Will be fedora-23 based for dom0 right?

This is the plan right now.

> Will I be able to use this build for day to day working in its current state? Or is it still too early?

A bit too early. Basically there are two major features missing:
- use HVM/PVHv2 instead of PV for everything
- GUI tools (new manager)

Besides that, there is _a lot_ of minor issues. And actually those minor
issues (like: time synchronization does not work) are most annoying and
IMO blocking daily usage.

Anyway, I'll write soon some more elaborate status update on Qubes 4.0,
on qubes-devel mailing list.

> I would also like to know what choices have been made regarding pvhvm or hvmlite as the main virtualization architecture?

In the current state of PVH(v2 aka HVMlite) in Xen, we've chosen to wait a little
with this, and for Qubes 4.0 use HVM with (still PV based) stubdomains.
When PVHv2 support will be mature enough, we'll smoothly switch to it
later (as a configuration option first).

> Is the fedora build the most complete? Or would debian have any benefits over fedora?

Both are supported and both should work. I think the only place that may
have some impact on compatibility is "Update VM" (the VM for downloading
dom0 updates) - here having the same tool (dnf) as in dom0 (Fedora)
makes it more compatible - for example you can issue any action (search,
list, etc.) instead of just "download all updates" / "install specific
package".

> What parameters should I pick? Version r4.0.0, with dev. Testing or something ? What about unstable vs security-testing?

Currently no binary package is uploaded to yum/apt repository (this is
where security-testing, unstable, current-testing, current repositories
are) for Qubes 4.0.
As for the source code - in most repositories "master" branch already
contains Qubes 4.0 code. There are few (but important!) exceptions,
where "core3-devel" branch should be used. We're working right now on
moving remaining code to "master" branch.

> Hope someone can explain how I can build myself a good r4.0 iso.

- --
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-----
Version: GnuPG v2

iQEcBAEBCAAGBQJYQA3gAAoJENuP0xzK19csBxAH/iTdN8K16EBuFnzqU3w+p8+j
38NmFkD8i/tjGAqtErQaCOpC3m9Pvy6TS7ZSSDJHOxuFtLngRix+Mm8dRHIpAk86
lKDEFV56r+BPO/iyLpPnCHGEPHtiszIfQHZe83WGdx84oCTKAuQ8TyIsCglFvPdi
YujuUE5xL0CtffBLxSGjK6lheE48ECuFes11ucO3wtyyvzocuJ+A3SZKtZUNhQPQ
H9RVpmPsdh7yopCSWWawEEdgfG6a8eyMpyvKy40qquYe8tMrg0NvRIjWrBte9gwU
8BK4kFCuBrPO0KmCq4gtiYKCKlP1zSI1N9ehnACKxG/489qafdrtVrorwGi10FA=
=XNj0
-----END PGP SIGNATURE-----

[bent...@cloudctrl.nl]

So, how should I configure my qubes-builder config file? Any chance you could maybe upload the config file that you've set the parameters for so I can have it build R4 build .iso ?

How long before hvm with pv stubs is implemented? Or is this one already in, and only pvh2 missing?

How long before gui management tools are ready? Are all the terminal management tools working? If so, I dont care, I could use some practice with the management commands in the terminal :).

By the way, I have a pgp-card, (Nitrokey) that I would like to use for security on my build. Any tips for how to best use one for solid full disk encryption? What storage layout should I use on a SSD with full disk crypto, for optimal security, and prefent evil maid attacks? I was wondering about if it would be possible to encrypt the whole disk, including boot? Or save boot on my nitrokey, and encrypt it, (grub encrypt) so thr usb gives the bootloader, the encryption password, the authentication over pgp, and maybe some more security certificates that are required for accessing the O.S.

The main thing I want to prevent is people tampering with my bootfiles to have a keylogger or something installed, or prevent people logging in using a password obtained with a hidden camera. I want my (disk encryption) security to be real 2 factor security requiring atleast my nitrokey, personal password, and if possible maybe a third factor to be able yo log in to my system, or even be able to unlock my filesystem.

Also,
What about the Tresor mod which saves your encryption key in the cpu? I really like the idea of being able to prevent people frm extracting the key from my ram. Any other tips for security ?

Thanks!

[bent...@cloudctrl.nl]

[bent...@cloudctrl.nl]

[bent...@cloudctrl.nl]

[bent...@cloudctrl.nl]

[bent...@cloudctrl.nl]

[Eva Star]

On 12/01/2016 02:47 PM, Marek Marczykowski-Górecki wrote:

>> R4 Will be fedora-23 based for dom0 right?
>
> This is the plan right now.
>

Why plans always point to old fedora release? Fedora 25 already
available. Why Qubes dom0 planed to be at fedora-23? (two versions delay)

And what is about fedora-25 template for AppVM? It will be available
when fedora 25 will be released? Is this "one version" delay, because it
take too much time to make new template or it's something security
related, because new fedora can be unstable?

And where is https://github.com/QubesOS/qubes-roadmap ?
What is about plans for beta releases of Q4 ?

--
Regards

[Andrew David Wong]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA512

On 2016-12-01 05:26, Eva Star wrote:
> On 12/01/2016 02:47 PM, Marek Marczykowski-Górecki wrote:
>
>>> R4 Will be fedora-23 based for dom0 right?
>>
>> This is the plan right now.
>>
>
> Why plans always point to old fedora release? Fedora 25 already available. Why Qubes dom0 planed to be at fedora-23? (two versions delay)
>

This doesn't answer the "why" question, but it's worth noting that dom0 has historically been based on older versions of Fedora, including EOL versions for periods of time. However, we don't consider this to be a security risk of any kind due to the way dom0 is isolated from domUs:

https://www.qubes-os.org/doc/supported-versions/#dom0

- --
Andrew David Wong (Axon)
Community Manager, Qubes OS
https://www.qubes-os.org
-----BEGIN PGP SIGNATURE-----

iQIcBAEBCgAGBQJYQCkOAAoJENtN07w5UDAw7yAQALRBb1BP3Y2BjKM8JEbkjpUL
yl7RbsLZwi21JQFw5TQFiIq4ZggkFpvQNFFAQDBShaPUfwVDVuTN53MC3eTJnFbj
AZ6C+vky/Xhem4K2Kgd/JKsXC4iTOntLJrqTBGRPH5R0c3VfsrsnN+Er7mSNxkps
Uf3Ekl8YxTDzTuG3jiuAhcxs5Zm771u3TR+fYzOO/IRl2zhuayQ7Xfu/R4x+u9ih
PKPJqperpKSVTB+go7inG4wH0UlNY67GsPDcme1n3OXdrfKgoRvHixBXyCXxedBC
4YA8q08YFLL0sdJKA2uMlYFpkcGJ1uzuEwJMtkf+eTUIinOa/Mz49qgyr//WivYz
GAa6ilUja15I7/B1f1qd73QCTQzWM0DFkvclpNceaqKF5UnHHmZ9mclPv9fXqAN2
d9V3uy/j8PyFhpE4E+dQKgovr/0lF1D5oBnMJs5W/BJOI8XO2+YcMHaTllQ2WyGI
JQvocnzeYA5BrwvdCgE5WZuhCOeldJM0M15Lk1LqfRyRaaj3iYt3auqlYc6dc4h4
/MkquV3ErTJwC8vcWY1D3N7w31kUzkTP8xBpYjtjntNqDsqZxrKxXf6IqrpqCPuJ
4tq97PzJtwx3G71ecBCR4qohYc5lWgt2WXrCGOsTQ1rXe+yHwVJkJ/rfI7CR3unY
tgQSAnjsFCsK2FuqvsHB
=KPMe
-----END PGP SIGNATURE-----

[Marek Marczykowski-Górecki]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256

On Thu, Dec 01, 2016 at 04:55:46AM -0800, bent...@cloudctrl.nl wrote:
> So, how should I configure my qubes-builder config file? Any chance you could maybe upload the config file that you've set the parameters for so I can have it build R4 build .iso ?

As I said, I'll write an update on this soon :)

If you really want it right now, here my builder.conf:
https://gist.github.com/marmarek/2e42558c3ad2c53b1e4bb49beb18c1a9

But I can't guarantee it will work out of the box.

> How long before hvm with pv stubs is implemented? Or is this one already in, and only pvh2 missing?

HW42 is working on updated stubdomain there, to have not-so-ancient qemu
inside. I think this is the only missing part, at least in theory.

> How long before gui management tools are ready? Are all the terminal management tools working? If so, I dont care, I could use some practice with the management commands in the terminal :).

Yes, most (all?) qvm-tools are working.

> By the way, I have a pgp-card, (Nitrokey) that I would like to use for security on my build. Any tips for how to best use one for solid full disk encryption? What storage layout should I use on a SSD with full disk crypto, for optimal security, and prefent evil maid attacks? I was wondering about if it would be possible to encrypt the whole disk, including boot? Or save boot on my nitrokey, and encrypt it, (grub encrypt) so thr usb gives the bootloader, the encryption password, the authentication over pgp, and maybe some more security certificates that are required for accessing the O.S.
>
> The main thing I want to prevent is people tampering with my bootfiles to have a keylogger or something installed, or prevent people logging in using a password obtained with a hidden camera. I want my (disk encryption) security to be real 2 factor security requiring atleast my nitrokey, personal password, and if possible maybe a third factor to be able yo log in to my system, or even be able to unlock my filesystem.
>
> Also,
> What about the Tresor mod which saves your encryption key in the cpu? I really like the idea of being able to prevent people frm extracting the key from my ram. Any other tips for security ?

Those questions deserve separate thread(s), but generally the answer is:
nice ideas, but not easy to implement in practice.

- --
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-----
Version: GnuPG v2

iQEcBAEBCAAGBQJYQCmrAAoJENuP0xzK19cs/1AIAJrqs+uOvAaJkxZnefMMvpCS
cptkkN9xZmQ23w26hGgwfmcCjpyYzWeZSMRbAtuLRd8lZZ11WojmCgMHKY/9iQgO
X9SqEPgD/OjAZswQK4PdeYw4K19mk72XV7KSbvdi1lONbTaFclu8ydcdjGvCz4gR
7WDUW1nnCkCwx/FeFWZGz6rKl6K7W6HjSSc4mAfpa/KWuIbIcjhZwMK6XMq24Vef
5WL66yg+W14Yzedc8PomnoW/ElIhvlJsWnOvFQjW8BnErfoGkBbuV46QedJ5f8JC
43Uh04DiUx1MsWIDHRpuyT6hbxEuxiTUeEBahxSceg7BSJ3/XqO3lCsDVI+nf9Y=
=tAlB
-----END PGP SIGNATURE-----

[Marek Marczykowski-Górecki]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256

On Thu, Dec 01, 2016 at 04:26:38PM +0300, Eva Star wrote:
> On 12/01/2016 02:47 PM, Marek Marczykowski-Górecki wrote:
>
> > > R4 Will be fedora-23 based for dom0 right?
> >
> > This is the plan right now.
> >
>
> Why plans always point to old fedora release? Fedora 25 already available.
> Why Qubes dom0 planed to be at fedora-23? (two versions delay)

To not delay Qubes 4.0 any more than necessary. Switching to new Fedora
release requires some work. And as Andrew pointed out, it isn't a
problem for security. If anything at all, some hardware compatibility,
but we will provide newer kernel at least.

> And what is about fedora-25 template for AppVM? It will be available when
> fedora 25 will be released? Is this "one version" delay, because it take too
> much time to make new template or it's something security related, because
> new fedora can be unstable?

Actually I have Fedora 25 already built and relevant packages are
already uploaded (as some users already noticed). Just some final
testing.

> And where is https://github.com/QubesOS/qubes-roadmap ?

https://github.com/rootkovska/qubes-roadmap

> What is about plans for beta releases of Q4 ?

See my other message.

- --
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-----
Version: GnuPG v2

iQEcBAEBCAAGBQJYQCrFAAoJENuP0xzK19csRcIH/ilLGvAFrIN70sCTdyBSEzaI
WoMFZ6guB5UeZR/iE+QnRagRkyAAMwkLO8M4x/IoZO+HuqqmdHMouFG4HN+3xQg3
Kw+n7akLF0n6cMaoO4cKNLaRP0sXgWXG9rJk+6KjsLzWO0HlcEvpQT+uN+M+caum
RfvgsyHoi9uvyEigOKtEFOTeaQM5sWu6zBa0ouAZ+WdkJQZftlfQOTAbC4sEPFVp
3WxL59noPFEGANOe8o2Tyw62kOruw40EuXPC6p0nohvQhixm9E9Zuu5iS1l4P3gZ
vEAFVZtH5eoIB4XiiP+/qNOHvq5YZYW3wsGdaZ7WYRPCnvutBHTcbDUK+3cdqgE=
=0ZH5
-----END PGP SIGNATURE-----

[C. L. Martinez]

On Thu 1.Dec'16 at 14:50:59 +0100, Marek Marczykowski-Górecki wrote:
> On Thu, Dec 01, 2016 at 04:26:38PM +0300, Eva Star wrote:
> > On 12/01/2016 02:47 PM, Marek Marczykowski-Górecki wrote:
> >
> > > > R4 Will be fedora-23 based for dom0 right?
> > >
> > > This is the plan right now.
> > >
> >
> > Why plans always point to old fedora release? Fedora 25 already available.
> > Why Qubes dom0 planed to be at fedora-23? (two versions delay)
>
> To not delay Qubes 4.0 any more than necessary. Switching to new Fedora
> release requires some work. And as Andrew pointed out, it isn't a
> problem for security. If anything at all, some hardware compatibility,
> but we will provide newer kernel at least.
>

To avoid this type of situations, why not use an LTS distro (CentOS, Unbuntu ...) for dom0??

--
Greetings,
C. L. Martinez

[Marek Marczykowski-Górecki]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256

In most cases LTS distro does not solve hardware compatibility problem
at all - you still get old drivers even if the release is still
supported. The only difference is how long bug fixes (for this outdated
software) are released.

So, generally it is good idea, but it will not solve this particular
problem. This is why we have this ticket:
https://github.com/QubesOS/qubes-issues/issues/1919
See discussion there for details.

- --
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-----
Version: GnuPG v2

iQEcBAEBCAAGBQJYQDFmAAoJENuP0xzK19csFscH/iK3SGKwkvtVwub61z2Mxh7s
Mbz8IfQ3s2TAAvHjL8ejE+1LzJYKqC60q5pi67BYD3OPXijSrOajfpahWVxO7EPz
HRaOxhwKzkTtvC2ZMNfOmFAnA6DNrqGewx8YceFbjk0SJm++CmbApfplqVV++wXL
FJwQlB3Sy9jM9d8LC/63BPalon5WUaPkkxcnd/LKmXfq4YWv9UcqsKGGY1NXFm65
Zx7Hqx22yJcU8zxWfpXp4x2vsipISP2L/3LbyzpCGNsam6W2Wz48RBqrs6MIjoBT
/UYufRLGpdahxrqYMOZDx4QzLmRkQ2QDY2ybbdB8qmhEipM3j2/C4etY7IgXJXk=
=a2Ik
-----END PGP SIGNATURE-----

[C. L. Martinez]

On Thu 1.Dec'16 at 15:19:16 +0100, Marek Marczykowski-Górecki wrote:
> On Thu, Dec 01, 2016 at 02:06:16PM +0000, C. L. Martinez wrote:
> > On Thu 1.Dec'16 at 14:50:59 +0100, Marek Marczykowski-Górecki wrote:
> > > On Thu, Dec 01, 2016 at 04:26:38PM +0300, Eva Star wrote:
> > > > On 12/01/2016 02:47 PM, Marek Marczykowski-Górecki wrote:
> > > >
> > > > > > R4 Will be fedora-23 based for dom0 right?
> > > > >
> > > > > This is the plan right now.
> > > > >
> > > >
> > > > Why plans always point to old fedora release? Fedora 25 already available.
> > > > Why Qubes dom0 planed to be at fedora-23? (two versions delay)
> > >
> > > To not delay Qubes 4.0 any more than necessary. Switching to new Fedora
> > > release requires some work. And as Andrew pointed out, it isn't a
> > > problem for security. If anything at all, some hardware compatibility,
> > > but we will provide newer kernel at least.
> > >
> >
> > To avoid this type of situations, why not use an LTS distro (CentOS, Unbuntu ...) for dom0??
>
> In most cases LTS distro does not solve hardware compatibility problem
> at all - you still get old drivers even if the release is still
> supported. The only difference is how long bug fixes (for this outdated
> software) are released.
>
> So, generally it is good idea, but it will not solve this particular
> problem. This is why we have this ticket:
> https://github.com/QubesOS/qubes-issues/issues/1919
> See discussion there for details.
>

Ok, understood ... But, IMO, CentOS (or any RHEL derived distro and RHEL) has a really good compatibility with old and new laptops (specially with thinkpads, acer aspire, etc.) and there is no problems with graphics drivers, nics, storage controllers, etc... I am using RHEL/CentOS/OL in all my laptops from 7 years ago without problems (yes, all of them they was/are thinkpads T).

Anyway, we can wait to Qubes 4.0 to see how it goes ..

Many thanks for your answer Marek.

[cubit]

1. Dec 2016 13:43 by a...@qubes-os.org:

we don't consider this to be a security risk of any kind due to the way dom0 is isolated from domUs:

Does using older and potentially EOL  distros for Dom0 leave it with out dated software that can be beneficial to users?  e.g. Updated XFCE will always bring improvements for like with dual monitor setups and other fixes better support for HiDPI monitoers.    With out these it seem to me that it means Qubes support gets relegated to older hardware with out fancy features.

Should user experience also be considered for major releases?

 

[Jean-Philippe Ouellet]

On Thu, Dec 1, 2016 at 7:55 AM, <bent...@cloudctrl.nl> wrote:
> Also, What about the Tresor mod which saves your encryption key in the cpu? I really like the idea of being able to prevent people frm extracting the key from my ram.

IMO not worth it in practice. See "TRESOR-HUNT: Attacking CPU-Bound
Encryption" paper.

https://dl.acm.org/citation.cfm?id=2420961
https://www.acsac.org/2012/openconf/modules/request.php?module=oc_program&action=view.php&a=&id=237&type=4

[Andrew David Wong]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA512

Yes, but we simply don't have the workforce at this point. Higher priority tasks consume all available developer bandwidth.

- --
Andrew David Wong (Axon)
Community Manager, Qubes OS
https://www.qubes-os.org
-----BEGIN PGP SIGNATURE-----

iQIcBAEBCgAGBQJYQJjFAAoJENtN07w5UDAweWIP/1uhEsizec0muw7ACQn6ku2z
ZM8WL9+xqTP7TKd+MYZes8PhkNyVTX7Wu3NHmhM4tTIZYdycMz76CutZG2W7buHU
S1WjgyQ1JdauITkRhN7L5kbvq8U81WqLI1KB522s6l/j4gsI/WX6D/QSE3O6pAl7
p+vL3itHzpDL7owPd9dDzMCPD4Bb1H9lYZc1Oy+Sx8vqyjBlAVpzM+fxZE6rGT+R
iNQZ7mnSA5PjqmFyVSGbPaIdiehfu8XG5PVNU/H5+unZ/9myCVOrLmUkdQCLxS1b
dSkFpVuTPFxFKngCP+VOuFKgO4vyGRgZA9f2lg7aE/hv7XIIxJb4XP5fKhkFvQvy
zOduWnYigZfHmBxoOWsmMQlVzQoE2WbI9TkopezQ0Q7ZFvI4KlIzlYdKHNLNKbvC
4awGSKe1RGbzvVRAD8qtPAplVy/ry9DqU4Ji5uU99z+O45KBHD0lvPAMQUbGawCY
Vn+NKqqizeBXEMuE14usEI6DBb0b2Bihf1nLMdkkK+yjFfPGbZWs6prGyG2Xl5MU
9/DG6FQJHTLbfzkIX5O47gPYl2759YU5Wt3pE33ILUgc4hBhn0n9k7cOJrCSWauO
imAbUoyC2veVPzUxNozrqrrBAeWOIBbgQHQ2tbNAjG+OSkWzNYir7Msik1nEdABH
nY4z2MgrD4f/eP+Eg6l3
=Y/eE
-----END PGP SIGNATURE-----

[bent...@cloudctrl.nl]

I get an error wheb running make get-sources when i get to libvirt library, ? Do I need to modify some sourcefile? Please help. BTW I just downloaded the qubes builder from qubes-os, and I used your config. Is this correct or should I be using a different qubes-builder?

[rspei...@gmail.com]

On Saturday, December 3, 2016 at 3:01:48 PM UTC-8, bent...@cloudctrl.nl wrote:
> I get an error wheb running make get-sources when i get to libvirt library, ? Do I need to modify some sourcefile? Please help. BTW I just downloaded the qubes builder from qubes-os, and I used your config. Is this correct or should I be using a different qubes-builder?

Same here, the error is:
No valid signed tag found!
Makefile:187: recipe for target 'core-libvirt.get-sources' failed

[bent...@cloudctrl.nl]

Could someone maybe give some help with the error message?

[Marek Marczykowski-Górecki]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256

On Thu, Dec 08, 2016 at 08:56:25AM -0800, bent...@cloudctrl.nl wrote:
> Could someone maybe give some help with the error message?

The one about missing signed tags? They are in place already - simply
retry. Take a look at "Qubes 4.0 development status update" message on
qubes-devel.

- --
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-----
Version: GnuPG v2

iQEcBAEBCAAGBQJYScb8AAoJENuP0xzK19cs1wUH/ArYL1S9mfT3GXv8K7pn/xnM
XVudxyPm/a1kx36Amg21w37d358vk8sT5tpZxvT2EjQxY9RnEWKc5B8EEMSPgQSY
N71g2ZkPlQTbjwIZTeU1otM/tBnmMcQtifd2mAkkIJJAYcGtCijlnlePauBqaa10
FXUxkVjEZs47cjF9n7f1mBwd5+4sONBWAxPBaHcgoiJTxFdQkzSDVWdtwrq57PQ9
1s/CF7IIv1+h3fHi5E3+/MqwKTdHgIlkYofaMU9A1z0L+08tCb6jpD2RcP9aP+Nj
52DCzp4rkjXdx5K1kJzaCgvGzL/7YII85MO/2f/CSozkXU/DdcGjgB8pXHM87ew=
=j5Qa
-----END PGP SIGNATURE-----

[Chris Laprise]

On 12/01/2016 09:19 AM, Marek Marczykowski-Górecki wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA256
>
> On Thu, Dec 01, 2016 at 02:06:16PM +0000, C. L. Martinez wrote:
>> On Thu 1.Dec'16 at 14:50:59 +0100, Marek Marczykowski-Górecki wrote:
>>> On Thu, Dec 01, 2016 at 04:26:38PM +0300, Eva Star wrote:
>>>> On 12/01/2016 02:47 PM, Marek Marczykowski-Górecki wrote:
>>>>
>>>>>> R4 Will be fedora-23 based for dom0 right?
>>>>> This is the plan right now.
>>>>>
>>>> Why plans always point to old fedora release? Fedora 25 already available.
>>>> Why Qubes dom0 planed to be at fedora-23? (two versions delay)
>>> To not delay Qubes 4.0 any more than necessary. Switching to new Fedora
>>> release requires some work. And as Andrew pointed out, it isn't a
>>> problem for security. If anything at all, some hardware compatibility,
>>> but we will provide newer kernel at least.
>>>
>> To avoid this type of situations, why not use an LTS distro (CentOS, Unbuntu ...) for dom0??
> In most cases LTS distro does not solve hardware compatibility problem
> at all - you still get old drivers even if the release is still
> supported. The only difference is how long bug fixes (for this outdated
> software) are released.

I have found Ubuntu LTS to be well maintained with driver updates over
the life of the release. Even if it were a problem in cases like Intel
Skylake individuals with cutting-edge hardware could still download
backported packages themselves.

Debian seems to be another matter... It has no true LTS (or, every
release is "LTS" if an external team puts in the effort). Its not
fastidious about maintaining device compatibility, and it doesn't
perform extensive testing and certification of actual hardware
configurations. So even though Debian benefits from a greater focus on
security and larger package selection, it still falls short of what a PC
OS should be in ways similar to Fedora.

Chris

[cubit]

1. Dec 2016 21:40 by a...@qubes-os.org:

Should user experience also be considered for major releases?

Yes, but we simply don't have the workforce at this point. Higher priority tasks consume all available developer bandwidth.

The user experience or even hardware support is an important one.  If people can't use it, Qubes is doing to languish in some obscurity,   should more developers be brought on?  

I know that is a matter of money or someone being generous with time but funding should be a possible route (ccing Michael Carbone) but I am sure hard work to gain or even applying for some like Google Summer of Code.

[Andrew David Wong]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA512

On 2016-12-16 03:50, cubit wrote:
> 1. Dec 2016 21:40 by a...@qubes-os.org:
>
>>> Should user experience also be considered for major releases?
>>>
>>
>> Yes, but we simply don't have the workforce at this point.
>> Higher priority tasks consume all available developer bandwidth.
>>
> The user experience or even hardware support is an important one.
> If people can't use it, Qubes is doing to languish in some
> obscurity,

That sounds like a false dichotomy. If you look at the context of this
conversation, we're talking about the rate at which dom0 is updated to
newer upstream distro releases, which is typically an incremental UX
and hardware support improvement, not an all-or-nothing ("usable" vs.
"unusable") matter.

> should more developers be brought on?
>
> I know that is a matter of money or someone being generous with
> time but funding should be a possible route (ccing Michael
> Carbone) but I am sure hard work to gain or even applying for some
> like Google Summer of Code.
>

See our recent post on this:

https://www.qubes-os.org/news/2016/11/30/qubes-commercialization/

- --
Andrew David Wong (Axon)
Community Manager, Qubes OS
https://www.qubes-os.org
-----BEGIN PGP SIGNATURE-----

iQIcBAEBCgAGBQJYU9pQAAoJENtN07w5UDAw4PoP/0pIe4JFFq/qG5gMQuQCTOCX
NtF3Kx/EPwYsvXkIK2yWMazv/YyyPi0Ze0ExMpaOzVeMo95MGdP3ZdVWMGH3JDo4
4jZBZZyr6rU5+I3f8ymc2MpDRaX1N1EGUlzzQFzDWejknGPqmOFpjAhz8ewY4LjU
Lk/U4YxagBgnQ8pAzTjC7NYvFq1f2rEqHwU3+TdyYvASBdOiRPcNg9hxsrQHphvm
ck3O7k9O07vZt21ppgJ6sNG2HhzdDltvMyd5EEUUPZ6X4Z8z3kbdNPKL+I3bVClD
mnoAL685ERLBSErbK/l3iCe8AY9aQGMNsmpAdNjNfavWjbv+oiE3OeGxgBNjPDlj
R057YFe3VrXxVdH4SdS4wWeczTMuLv27eeJ7qSSEG3z+tFF3NUMAahBUqHMQhQOY
dHdBSme7VGN21msOV6raihME+ZGbX4BInk6f8HJqNzHSU/f/JjfJUnxmyKlGoTAi
eQHtzM2ipJnbOglV1YJ6ycS70idiUjLxmU84Gqd3ofjg4Mmif5QQZk8ZpjHzZkx0
jmcB/Ifx9ku5WtVZehuuRQIsMPESXMp/glh4yvmhFSmwBoZgJa4LnuHx1uRTudHn
ltxyUWLKlTUMNUhfFQqTqCKBUanNDaW4anuvDCV4tKwNms12hIES6YeN248yW458
AU0cl5kXUC9Ak6ABKwql
=Z1d4
-----END PGP SIGNATURE-----

[bent...@cloudctrl.nl]

Next error is for core3-admin.get-sources, repo not found, this is from your repo, can you fix this? Any chance you can meet me on some chat so we can work out all errors at once?

[HiringQubesExperts]

On Thursday, 8 December 2016 21:48:05 UTC+1, Marek Marczykowski-Górecki wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA256
>

> On Thu, Dec 08, 2016 at 08:56:25AM -0800, wrote:
> > Could someone maybe give some help with the error message?
>
> The one about missing signed tags? They are in place already - simply
> retry. Take a look at "Qubes 4.0 development status update" message on
> qubes-devel.
>
> - --
> 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-----
> Version: GnuPG v2
>
> iQEcBAEBCAAGBQJYScb8AAoJENuP0xzK19cs1wUH/ArYL1S9mfT3GXv8K7pn/xnM
> XVudxyPm/a1kx36Amg21w37d358vk8sT5tpZxvT2EjQxY9RnEWKc5B8EEMSPgQSY
> N71g2ZkPlQTbjwIZTeU1otM/tBnmMcQtifd2mAkkIJJAYcGtCijlnlePauBqaa10
> FXUxkVjEZs47cjF9n7f1mBwd5+4sONBWAxPBaHcgoiJTxFdQkzSDVWdtwrq57PQ9
> 1s/CF7IIv1+h3fHi5E3+/MqwKTdHgIlkYofaMU9A1z0L+08tCb6jpD2RcP9aP+Nj
> 52DCzp4rkjXdx5K1kJzaCgvGzL/7YII85MO/2f/CSozkXU/DdcGjgB8pXHM87ew=
> =j5Qa
> -----END PGP SIGNATURE-----

Im really sorry for the trouble, but I am still getting loads of errors all the way, even when modifying some things by hand to make it work, errors errors errors.

Could you maybe make me a new config file, and make sure that it works before posting it? Maybe also post the exact steps you use to make the whole thing work ? Are you doing anything specials? Ignoring any stuff using -i while running the make command?

[HiringQubesExperts]

On Wednesday, 30 November 2016 17:49:06 UTC+1, bent...@cloudctrl.nl wrote:
> Hi,
>
> I've been using Qubes-OS since R2, and I would like to start using the development build so I can try and do some testing for some unikernel and mirage-based security stuff I want to implement.
>
> Can someone tell me where I can get the files? Any tips or hints when it comes to running the latest build?
>
> Hope someon can help me get it.
>
> P.S.
> How long before the first rc will be released? This shouldnt be much longer right?

Hello? Can someone please give me an update on this topic? I would really like to build 4.0 ...

[Marek Marczykowski-Górecki]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256

Have you seen this message:

https://groups.google.com/d/topic/qubes-devel/2DMBT2eBbyw/discussion

?

- --
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-----
Version: GnuPG v2

iQEcBAEBCAAGBQJYbEWGAAoJENuP0xzK19cs3h4H/3gh2Bfkfm3fuO46zlkICGo+
uYk1MnjELy7/u4+YaBLWA9bmC9+s3xmGbMR0KmjmgeCnw9DFPVJe8LdAN6MvYmNy
XQJW4wqnE7QhvlzZkQpiIoRxg8qCcATFPCXEzAuNCpTXnVGMvlGFgswc6bbZ3TjE
hPhdDUCNF5KikXUFSxNjchozlirVQ1htHwjnzi3VS2yXVRN9KA4VNgx8nVxx5qT2
epmf5nqd+j3wQOtk0aYsCuYpuJUgwtheK4Oev7uFjBH6hnsUfguVJK89MsiJZ7Bi
RZvP8o7JdHKJ2AfNeDEJhrFo3+9EQyAKzvXKjSD/8aIMm6SULe+QOpESJyj5qDE=
=bAWY
-----END PGP SIGNATURE-----

[img2...@gmail.com]

Le mercredi 30 novembre 2016 18:34:34 UTC+1, Jean-Philippe Ouellet a écrit :

> On Wed, Nov 30, 2016 at 11:49 AM, <bent...@cloudctrl.nl> wrote:
> > Can someone tell me where I can get the files? Any tips or hints when it comes to running the latest build?
>

> I am not aware of any publicly-available full "development builds",
> however qubes-builder[1] makes it very easy to build them yourself..
>
> [1]: https://www.qubes-os.org/doc/qubes-builder/

hello, could you explain me how to use qubes-builder please?
i want to try qubes 4.0, don't know how to do it.
thanks

[Unman]

Did you read the doc that was linked?
What is it that you don't understand?

There is additional information in the doc folder, and the example
configs are (generally) well commented.

The basic idea is that qubes-builder will allow you to specify *what*
you want to build (either using the setup script, or providing your own
builder.conf based on the examples, and then download the sources,
verify them and allow you to build individual packages or full
templates as you wish.

You can get started by following the instructions on the linked page, or
in the building-archlinux-template document.
I would strongly suggest that you do a basic build first, using the
./setup script, and then run make and look at the available build
options.
Once you have done a quick build (use a minimal flavour), change the
release to 'master' and start building from there.

If you encounter specific problems ask again

cheers

unman