Congrats, debian-vm, lvm-lv, encrypted VMs, security-by-faith

404 views
Skip to first unread message

chymian

unread,
Jun 2, 2014, 3:54:36 PM6/2/14
to qubes...@googlegroups.com
hello,

fairly new to – and very excited about, qubes, it looks like it is, what I looked for a long time. where have you been hiding? ;-)
a big thank to you johanna, marek & everybody who was participating to help, realizing (one of) my (IT-) dream(s).

I did a _lot_ of reading in the last 10 days, but there are still some open questions.
background: coming from a debian/KDE centric ws, with about 2 dozens of kvm-vms, mostly DEB & Ubu, living on logical-volumes

debian-template:
I created the debian template with the no longer supported standalone script from david, which worked quite well.
the VM does most of the things it should, but there are a few glitches, which are probably well known:
* pulsedaemon seg-faulting, (has been reported)
* gnome-terminal does not show input, but konsole workes fine.
* kde-menu pop-up-windows show white instead of menu-entries on first pull-down or right-click. works after the 2nd time.
* qvm-copy-to-vm: works well, but not from dolphin

I’ve seen a patchset for the template builder about a month ago on the devel-list, and discussed corrections, but actually no newer patch set.
what is the status of the debian template at all?

Using LVM logical Volumes in VMs.
following a answermail from marek, I tried to get access to the LVs, but the patch seems to be outdated (out of my head: arround 2011, sorry, don’t find the mail it at the moment, but was about patching udev-block-add?? and some python scripts). anyway, what is the preferred way of doing that with R2 rc1?
goal is, to use my existent data/home partitions & my kvm-vms.

GNOME in VMs:
the mixture of KDE dom0 & Gnome in the VMs (which I don’t understand, but probably has been discussed before – link available?) does not work correctly in my hw-setup, laptop with ext. monitor.
the pull-down menus of gnome terminal (and other gnome-apps) do show on my laptop screen at the border, when the window is on my hdmi-attached external monitor.
on has to move the window to the laptop screen on every use of the pull-down-menu, than back to the big screen…

encrypted partitions:
in the arch-paper, there was description, that every VM will have there own encrypted private disk space. but it’s not.
I liked the idea, so what is the reason that this not the default?
is it implemented/is it possible to do that?



qvm-block -d not working reliable?
during the process of creating the deb-template, I often crossmounted root.img to the work-vm, to do chrooted install, etc.
I realized, that there is:

a: no cmd, to see the status of what is qvm-block-mounted where.
b: "qvm-block -A vm file" does work
"qvm-block -d file” doesn’t – throws an error – always
c: "qvm-block -d vm” works only sometimes.
unmounted xvdi within the work-vm,
issued "qvm-block -d…”
and checking with blkid, still shows xvdi connected.
no way to disconnect, but rebooting work-vm


general install question:
so, I used the BTRFS setup, assuming the various partitions from the various VMs would have subvolumes, snapshot, etc available. but they do not – yet?
what is the difference from LVM, LVM-thin-provisioning & BTRFS setup? I haven’t found any description, especially in the installation- or arch-paper?

dom0
there was a discussion about moving dom0 to debian. great idea, btw – IMHO ;)
is it still a goal?

template-builder, vagrant & Security-by-Faith?
I’ve seen, that there will be support to use chef, puppet, etc in R3 – which is very good news.
will there be a thing like vagrant or dockerfile, to build the templates itself?
which is preferable over a ready build rpm from “somebody”, who uploaded it to the community-repro, leaves everybody in his/her believe, that it should be secure, clean & without any nasty code within it.
or: with all the concerns about security, I would N.E.V.E.R. use the community-template store.
sorry, nothing personal, but what’s there can simple not be considered secure by default, only by believe, since there is no proof that it is vanilla OS, and nobody has tampered with it.

so, I do trust debian (name your fav. distro here) and usually start from a self created debootstrap mini install/template.
I would trust you ITL, if you release (mini-) templates.
*** end of list ***




I would be glad, if someone could answer the questions or point me to the readings I have missed.
at the moment, the LVM support is essential to me, to move ahead.

so again, I’m very happy that there is qubesOS – which makes a whole lot of sens and is _usable_ implemented security. :)
thanks again & I’m also eagerly looking forward to what’s coming with R3! :)


TIA
günter

Qubes-HCL-CLEVO_CO._-W150ER_-20140529-191947.txt

Hakisho Nukama

unread,
Jun 3, 2014, 5:35:14 AM6/3/14
to chymian, qubes...@googlegroups.com
Hey Günter,

I assume your laptop is working without problems?
I've added an entry to our HCL [1].

Some long time ago I've tried a Qubes installation with BTRFS,
but was disappointed by the performance.
Where there significant improvements on the performance of volumes
on top of BTRFS?

Best Regards,
Hakisho Nukama

[1] https://www.qubes-os.org/trac/wiki/HCL?action=diff&version=169

Marek Marczykowski-Górecki

unread,
Jun 3, 2014, 11:28:06 PM6/3/14
to chymian, qubes...@googlegroups.com, Davíð Steinn Geirsson
On 02.06.2014 21:54, chymian wrote:
> hello,
>
> fairly new to – and very excited about, qubes, it looks like it is, what I looked for a long time. where have you been hiding? ;-)
> a big thank to you johanna, marek & everybody who was participating to help, realizing (one of) my (IT-) dream(s).
>
> I did a _lot_ of reading in the last 10 days, but there are still some open questions.
> background: coming from a debian/KDE centric ws, with about 2 dozens of kvm-vms, mostly DEB & Ubu, living on logical-volumes
>
> debian-template:
> I created the debian template with the no longer supported standalone script from david, which worked quite well.
> the VM does most of the things it should, but there are a few glitches, which are probably well known:
> * pulsedaemon seg-faulting, (has been reported)
> * gnome-terminal does not show input, but konsole workes fine.
> * kde-menu pop-up-windows show white instead of menu-entries on first pull-down or right-click. works after the 2nd time.
> * qvm-copy-to-vm: works well, but not from dolphin

Adding cc: Davíð to make sure he receive it. But those problems will be fixed
probably only after finishing base template-building scripts.

> I’ve seen a patchset for the template builder about a month ago on the devel-list, and discussed corrections, but actually no newer patch set.
> what is the status of the debian template at all?

Davíð, did you have time for finishing template-builder integration?

> Using LVM logical Volumes in VMs.
> following a answermail from marek, I tried to get access to the LVs, but the patch seems to be outdated (out of my head: arround 2011, sorry, don’t find the mail it at the moment, but was about patching udev-block-add?? and some python scripts). anyway, what is the preferred way of doing that with R2 rc1?
> goal is, to use my existent data/home partitions & my kvm-vms.

Probably that patch need to be updated. I don't remember details, but if you
have separate VG with those VMs, you probably can assign raw PV to the VM and
activate LVM there.

Anyway Nested VT-x isn't supported in Qubes, so KVM will probably won't work
in the VM.

> GNOME in VMs:
> the mixture of KDE dom0 & Gnome in the VMs (which I don’t understand, but probably has been discussed before – link available?)

This mixture indeed was discussed many times here. There isn't any hard
reasoning behind that - we've started with KDE in dom0 at the beginning (as
full featured, easily customizable desktop environment), then needed some
lightweight apps in VMs (to save as much RAM as possible in single VM) - Gnome
ones was lighter than KDE ones.
But you can install whatever you want in VM template. Also you can choose to
have KDE or Xfce in dom0.

> does not work correctly in my hw-setup, laptop with ext. monitor.
> the pull-down menus of gnome terminal (and other gnome-apps) do show on my laptop screen at the border, when the window is on my hdmi-attached external monitor.
> on has to move the window to the laptop screen on every use of the pull-down-menu, than back to the big screen…

This looks like some new bug introduced recently by one of Fedora (or our)
updates. I have the same problem for few weeks, but it worked before. Dom0
window manager is most likely irrelevant here - VM application have no way to
talk to it directly. I use Xfce4 and have the same problem.

> encrypted partitions:
> in the arch-paper, there was description, that every VM will have there own encrypted private disk space. but it’s not.
> I liked the idea, so what is the reason that this not the default?
> is it implemented/is it possible to do that?

It isn't implemented and probably won't be. The gains (over single single
encrypted partition) compared to work needed to implement it fully are too little.

> qvm-block -d not working reliable?
> during the process of creating the deb-template, I often crossmounted root.img to the work-vm, to do chrooted install, etc.
> I realized, that there is:
>
> a: no cmd, to see the status of what is qvm-block-mounted where.
> b: "qvm-block -A vm file" does work
> "qvm-block -d file” doesn’t – throws an error – always

You can list attached devices with qvm-block -l. Attached file will show as
"loop" device.

> c: "qvm-block -d vm” works only sometimes.
> unmounted xvdi within the work-vm,
> issued "qvm-block -d…”
> and checking with blkid, still shows xvdi connected.
> no way to disconnect, but rebooting work-vm

Does qvm-block also list that device as connected?

> general install question:
> so, I used the BTRFS setup, assuming the various partitions from the various VMs would have subvolumes, snapshot, etc available. but they do not – yet?
> what is the difference from LVM, LVM-thin-provisioning & BTRFS setup? I haven’t found any description, especially in the installation- or arch-paper?

Qubes currently doesn't use of any special features of underlying
device/filesystem. All the data are stored in /var/lib/qubes in sparse files.
So unless you manually set up multiple volumes, or use those features in some
other means, its pretty irrelevant which layout you choose. The most tested
option is LVM. Regarding the differences, have a look here:
http://docs.fedoraproject.org/en-US/Fedora/20/html/Installation_Guide/s1-diskpartsetup-x86.html

BTW there are people here working on making use of LVM volumes, btrfs
features, or even ZFS pools, but I haven't seen anything ready for testing yet.

> dom0
> there was a discussion about moving dom0 to debian. great idea, btw – IMHO ;)
> is it still a goal?

This is pretty irrelevant which distribution is in dom0, all your
applications, files etc are in VMs and there you spend most of the time. So
unless there is some really good argument for that, we will not to change dom0
distribution and will focus on some useful features.

> template-builder, vagrant & Security-by-Faith?
> I’ve seen, that there will be support to use chef, puppet, etc in R3 – which is very good news.
> will there be a thing like vagrant or dockerfile, to build the templates itself?
> which is preferable over a ready build rpm from “somebody”, who uploaded it to the community-repro, leaves everybody in his/her believe, that it should be secure, clean & without any nasty code within it.
> or: with all the concerns about security, I would N.E.V.E.R. use the community-template store.
> sorry, nothing personal, but what’s there can simple not be considered secure by default, only by believe, since there is no proof that it is vanilla OS, and nobody has tampered with it.
>
> so, I do trust debian (name your fav. distro here) and usually start from a self created debootstrap mini install/template.
> I would trust you ITL, if you release (mini-) templates.
> *** end of list ***

I clearly understand that. So as with most of open source project you have a
choice:
a) trust the provided binaries (by template maintainer in this case)
b) build the template (and updates!) yourself

If you choose the second option, preferred way is to use Qubes Builder[1].
Archlinux support is already incorporated, Debian hopefully will be soon.
It is really simple to use, after filling builder.conf (including setting
appropriate DISTS_VM), you need to call:
make qubes-vm template
And you will get template rpm package ready to install in Qubes dom0.

[1] http://qubes-os.org/trac/wiki/QubesBuilder

> I would be glad, if someone could answer the questions or point me to the readings I have missed.
> at the moment, the LVM support is essential to me, to move ahead.
>
> so again, I’m very happy that there is qubesOS – which makes a whole lot of sens and is _usable_ implemented security. :)
> thanks again & I’m also eagerly looking forward to what’s coming with R3! :)
>
>
> TIA
> günter
>


--
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?

signature.asc

Davíð Steinn Geirsson

unread,
Jun 4, 2014, 2:34:42 PM6/4/14
to Marek Marczykowski-Górecki, chymian, qubes...@googlegroups.com
Hi Marek & Günter,

On Wed, 04 Jun 2014 05:27:57 +0200
Marek Marczykowski-Górecki <marm...@invisiblethingslab.com> wrote:

> On 02.06.2014 21:54, chymian wrote:
> > hello,
> >
> > fairly new to – and very excited about, qubes, it looks like it is,
> > what I looked for a long time. where have you been hiding? ;-) a
> > big thank to you johanna, marek & everybody who was participating
> > to help, realizing (one of) my (IT-) dream(s).
> >
> > I did a _lot_ of reading in the last 10 days, but there are still
> > some open questions. background: coming from a debian/KDE centric
> > ws, with about 2 dozens of kvm-vms, mostly DEB & Ubu, living on
> > logical-volumes
> >
> > debian-template:
> > I created the debian template with the no longer supported
> > standalone script from david, which worked quite well. the VM does
> > most of the things it should, but there are a few glitches, which
> > are probably well known:
> > * pulsedaemon seg-faulting, (has been reported)

I know of this problem, it'll be a priority to solve it once I have
more time to work on the template.

> > * gnome-terminal does not show input, but konsole workes fine.

I think this is a gnome issue. I saw similar behaviour in the fedora
template for a while (might be fixed now). The problem is that
gnome-terminal defaults to "system color scheme", which has the same
background and text colour. If you go into the settings dialog, you can
pick a different colour scheme. I might just switch to xfce-terminal as
default.

> > * kde-menu pop-up-windows show white instead of menu-entries on
> > first pull-down or right-click. works after the 2nd time.
> > * qvm-copy-to-vm: works well, but not from dolphin

I'll have to look into these two issues, thanks for reporting them.

>
> Adding cc: Davíð to make sure he receive it. But those problems will
> be fixed probably only after finishing base template-building scripts.
>
> > I’ve seen a patchset for the template builder about a month ago on
> > the devel-list, and discussed corrections, but actually no newer
> > patch set. what is the status of the debian template at all?
>
> Davíð, did you have time for finishing template-builder integration?


Unfortunately no, I've been quite busy and haven't had time to work on
it lately. Hopefully I'll get around to it soon.
Seems sensible. Personally I would much prefer dom0 to be debian-based,
but since qubes has already gone with fedora, changing that at this
point would be a lot of work for limited benefit. Certainly a lot
harder than getting a new template to work.

>
> > template-builder, vagrant & Security-by-Faith?
> > I’ve seen, that there will be support to use chef, puppet, etc in
> > R3 – which is very good news. will there be a thing like vagrant or
> > dockerfile, to build the templates itself? which is preferable over
> > a ready build rpm from “somebody”, who uploaded it to the
> > community-repro, leaves everybody in his/her believe, that it
> > should be secure, clean & without any nasty code within it. or:
> > with all the concerns about security, I would N.E.V.E.R. use the
> > community-template store. sorry, nothing personal, but what’s there
> > can simple not be considered secure by default, only by believe,
> > since there is no proof that it is vanilla OS, and nobody has
> > tampered with it.
> >
> > so, I do trust debian (name your fav. distro here) and usually
> > start from a self created debootstrap mini install/template. I
> > would trust you ITL, if you release (mini-) templates. *** end of
> > list ***
>
> I clearly understand that. So as with most of open source project you
> have a choice:
> a) trust the provided binaries (by template maintainer in this case)
> b) build the template (and updates!) yourself

Interesting, I thought the plan was that ITL would build the community
templates once they are added to the template-builder. At least that
was my reading from this post by Joanna:

http://theinvisiblethings.blogspot.com/2014/04/qubes-os-r2-rc1-has-been-released.html

Has this changed?

I think it would be better if ITL can build the templates and packages,
since it means they can all get security updates at the same time, from
the same people who get notifications of security issues in qubes code.
Otherwise the non-fedora templates will always be second-class citizens
in qubes.
signature.asc

Marek Marczykowski-Górecki

unread,
Jun 6, 2014, 11:16:23 PM6/6/14
to chymian, qubes...@googlegroups.com
On 04.06.2014 18:30, chymian wrote:
> hello marek,
> thanks for taking time to answer.
>
>>> Using LVM logical Volumes in VMs.
>>> following a answermail from marek, I tried to get access to the LVs, but
> the patch seems to be outdated (out of my head: arround 2011, sorry, don’t find
> the mail it at the moment, but was about patching udev-block-add?? and some
> python scripts). anyway, what is the preferred way of doing that with R2 rc1?
>>> goal is, to use my existent data/home partitions & my kvm-vms.
>>
>> Probably that patch need to be updated. I don't remember details, but if you
>> have separate VG with those VMs, you probably can assign raw PV to the VM
> and activate LVM there.
>
> that would work only for my data-partions and if I use all of them within one
> VM, and doesn’t give me the flexibility, to use diff. lvs within a vg in
> different VMs?
> within HVM-setup: it's already possible there, so one could think it's just a
> little tweak somewhere.

Done, will be in next qubes-core-dom0 (plus qubes-utils) package.

>> Anyway Nested VT-x isn't supported in Qubes, so KVM will probably won't work
>> in the VM.
>
> I don’t plan to nest VMs, I want to use my former KVM-VMs as ZEN-VM – should
> be makeable without changing the vms, but install the qubes-tools in them.
>
> so, the questions is, how to get qubes to see all lvs, that I can assign them
> to diff. VMs, basically, the same as with the data-part. above. but using a lv
> (with partition-table) instead of root.img in a HVM-setup. also not using
> private.img & volatile.img.

I'm afraid this part (using lvm instead of root.img) can be currently done
only with qvm-start --custom-config.

> that, and using pure data-partitions within diff. VMs would strengthen your
> migration path for existing systems.
>
> if there's no easy way at the moment, I/we probably have to wait for R3
> libvirt support. because this is a typical installation method in libvirt-vm-
> manager, that should do it, right?
> or will it not be possible to use the xen-setup with it? meaning eliminate
> root.img, priv… in favor of a all-lv-based VM?
>
> btw:
> I was playing around to create a new HVM standalone VM, which throws a critcal
> error:
>
> IndexError: list index out of range at line 158
> of file /usr/lib64/python2.7/site-packages/qubesmanager/create_new_vm.py

The code suggests you've tried to create non-standalone VM, without template
set. Fixed to make the message clear.

>>> qvm-block -d not working reliable?
>>> during the process of creating the deb-template, I often crossmounted
> root.img to the work-vm, to do chrooted install, etc.
>>> I realized, that there is:
>>>
>>> a: no cmd, to see the status of what is qvm-block-mounted where.
>>> b: "qvm-block -A vm file" does work
>>> "qvm-block -d file” doesn’t – throws an error – always
>>
>> You can list attached devices with qvm-block -l. Attached file will show as
>> "loop" device.
>
> sorry, but no, they don't.
>
>>
>>> c: "qvm-block -d vm” works only sometimes.
>>> unmounted xvdi within the work-vm,
>>> issued "qvm-block -d…”
>>> and checking with blkid, still shows xvdi connected.
>>> no way to disconnect, but rebooting work-vm
>>
>> Does qvm-block also list that device as connected?
>
> double checked:
>
> qvm-block -A work dom0:/var/lib/qubes/vm-templates/debian-jessie-mini/root.img
>
> ->> checked in vm work: available using blkid
>
> guenter@dom0 ~
> $ qvm-block -l
> dom0:sda Hitachi_HTS547575A9E384 () 698 GiB
> dom0:sdc SAMSUNG_HM500JI () 465 GiB
> dom0:sda1 Hitachi_HTS547575A9E384 (qubes-/boot) 500 MiB
> dom0:sdc1 SAMSUNG_HM500JI (hunab-ku) 465 GiB
> dom0:sdb4 M4-CT128M4SSD2 () 2 MiB
> dom0:sdb5 M4-CT128M4SSD2 () 26 GiB
> dom0:sdb6 M4-CT128M4SSD2 () 59 GiB
> dom0:sdb1 M4-CT128M4SSD2 (EFI) 188 MiB
> dom0:sdb3 M4-CT128M4SSD2 () 7 GiB
> dom0:sda5 Hitachi_HTS547575A9E384 () 32 GiB
> dom0:sda4 Hitachi_HTS547575A9E384 () 871 KiB
> dom0:sdb8 M4-CT128M4SSD2 () 25 GiB
> dom0:sda3 Hitachi_HTS547575A9E384 () 657 GiB
> dom0:sda2 Hitachi_HTS547575A9E384 () 7 GiB
> guenter@dom0 ~
> $ qvm-block -d dom0:/var/lib/qubes/vm-templates/debian-jessie-mini/root.img
> Usage: qvm-block -l [options]
> usage: qvm-block -a [options] <vm-name> <device-vm-name>:<device>
> usage: qvm-block -A [options] <vm-name> <file-vm-name>:<file>
> usage: qvm-block -d [options] <device-vm-name>:<device>
> usage: qvm-block -d [options] <vm-name>
> List/set VM block devices.
>
> qvm-block: error: Invalid VM or device name: dom0:/var/lib/qubes/vm-
> templates/debian-jessie-mini/root.img

Ah, file in /var/lib/qubes. Those are considered as "system files" and not
listed in qvm-block by default. You can list them with qvm-block
--show-system-disks.

Anyway to access template root.img, its better to simply start the template
(if possible). Otherwise you're risking mounting the same disk image from
multiple locations which will most likely cause filesystem corruption. Of
course there are cases (like this with working on new template) where
attaching root.img to other VM would be beneficial.

>
> ->> there should be a function like this (the opposite of -A), because if one
> has mounted more then on image-file to a vm – which is allowed, how to
> specifically unmount one of them?
>
> $ qvm-block -d work && echo unmounted
> unmounted
>
> ->> still available within work, blkid and mountable
> & qvm-block is giving back a ok status instead of an error!
>
>
>
>>
>>> general install question:
>>> so, I used the BTRFS setup, assuming the various partitions from the
> various VMs would have subvolumes, snapshot, etc available. but they do not –
> yet?
>>> what is the difference from LVM, LVM-thin-provisioning & BTRFS setup? I
> haven’t found any description, especially in the installation- or arch-paper?
>>
>> Qubes currently doesn't use of any special features of underlying
>> device/filesystem. All the data are stored in /var/lib/qubes in sparse files.
>> So unless you manually set up multiple volumes, or use those features in
> some
>> other means, its pretty irrelevant which layout you choose. The most tested
>> option is LVM. Regarding the differences, have a look here:
>> http://docs.fedoraproject.org/en-US/Fedora/20/html/Installation_Guide/s1-diskpartsetup-x86.html
>>
>> BTW there are people here working on making use of LVM volumes, btrfs
>> features, or even ZFS pools, but I haven't seen anything ready for testing
> yet.
>
> ah, ok, understand it’s just fedora-installer heritage, not qubesOS VM
> provisioning.

Exactly.

>>> dom0
>>> there was a discussion about moving dom0 to debian. great idea, btw – IMHO
> ;)
>>> is it still a goal?
>>
>> This is pretty irrelevant which distribution is in dom0, all your
>> applications, files etc are in VMs and there you spend most of the time. So
>> unless there is some really good argument for that, we will not to change
> dom0 distribution and will focus on some useful features.
>
> like: qubesOS, with it fedora-centric appearance has very a small known-
> footprint in the debian/ubu/mint/etc… world (biggest desktop-linux base),
> which probably would change fast, if you make dom0 a debian system.
> but hey, I totally understand you and I can live with fedora in dom0.
> marketing wise: its another decision…
signature.asc

Joanna Rutkowska

unread,
Jun 12, 2014, 9:02:18 AM6/12/14
to Davíð Steinn Geirsson, Marek Marczykowski-Górecki, chymian, qubes...@googlegroups.com
On 06/04/14 20:34, Davíð Steinn Geirsson wrote:
>>> so, I do trust debian (name your fav. distro here) and usually
>>> > > start from a self created debootstrap mini install/template. I
>>> > > would trust you ITL, if you release (mini-) templates. *** end of
>>> > > list ***
>> >
>> > I clearly understand that. So as with most of open source project you
>> > have a choice:
>> > a) trust the provided binaries (by template maintainer in this case)
>> > b) build the template (and updates!) yourself
> Interesting, I thought the plan was that ITL would build the community
> templates once they are added to the template-builder. At least that
> was my reading from this post by Joanna:
>
> http://theinvisiblethings.blogspot.com/2014/04/qubes-os-r2-rc1-has-been-released.html
>
> Has this changed?
>
> I think it would be better if ITL can build the templates and packages,
> since it means they can all get security updates at the same time, from
> the same people who get notifications of security issues in qubes code.
> Otherwise the non-fedora templates will always be second-class citizens
> in qubes.
>

As indicated earlier, ITL will build (from sources) and sign the
community-contributed templates, and we will upload them to
itl-community repos. However, we don't want to be involved with building
and uploading of *updates* for those templates, be that qubes-releated
(e.g. updates to qubes-core-vm packages) or not. Those should be taken
care by the person who contributed the template (e.g. David in case of
Debian template, Olivier in case of Arch Linux, etc). We really don't
have resources to be able to test and debug the updates for more than
the basic template. Of course, by building and singing the specific
community template we will include the public signing keys of the person
that we decide should be responsible for the updates (inserting of the
keys should be part of the template building scripts).

If somebody doesn't trust "the community", then probably should not be
using any other Linux distro either...

joanna.

signature.asc

Alex Dubois

unread,
Jun 13, 2014, 9:16:36 AM6/13/14
to Joanna Rutkowska, Davíð Steinn Geirsson, Marek Marczykowski-Górecki, chymian, qubes...@googlegroups.com


Alex
Would be nice to build a tool to allow community contributor to validate your binaries vs source the have compiled and to get the source (single commit) signed by individual contributors...

Marek Marczykowski-Górecki

unread,
Jul 2, 2014, 6:18:53 PM7/2/14
to Davíð Steinn Geirsson, chymian, qubes...@googlegroups.com
Did you made any progress? Perhaps I can help you somehow?
signature.asc
Reply all
Reply to author
Forward
0 new messages