<jpo>
alj[m]: central filesystem has severe disadvantages from a security perspective. i'm not saying it can't still be done reasonably (and i think there's definitely unexplored areas of the design space with plenty of room for spectrum to experiment), but it's not appropriate for qubes, because (as you're probably already aware, but repeating for the non-qubes people) the complexity of the filesystem API represents a much more concerning attack surface than simple
<jpo>
now, as for the user configuration maintenance woes, yes, this is a known pain-point. personally i've solved it with a simple script in dom0 that sends what config i want to a target vm and unpacks it in the user dir. much easier than messing with salt, and not a security issue because it's a trivial unidirectional pipe into the VM, with explicitly nothing back out, and from the most-trusted area (dom)
<jpo>
*0)
<jpo>
this could be done from not-dom0 as well via the management API, but, meh. the simplicity is appropriate for my specific use case
<jpo>
there are two other categories of solutions: symlinks from ~/... to the template-backed root fs, and bind-mounts (https://www.qubes-os.org/doc/bind-dirs/)
<jpo>
those latter two solving the fundamental problem of user state propagation being stale by only grabbing the copy at the time the appvm was created, by pointing it at a non-stale copy which can be maintained in a single place in the templateVM
<jpo>
these things admittedly could use some UI help to expose them in a friendlier way to users
<jpo>
but reaching for the decrease-isolation-strength solution by way of shared filesystems is not the direction for Qubes' design goals
* jpo
goes back to perpetual idle
<jpo>
oh yeah, and about the space consumption issue: i suspect you might be misinterpreting what's going on. you can't easily "shrink" the allocated space as in `qvm-volume resize ...` (actually... you can, even safely, but only after manually shrinking the fs in the guest first) or via the settings UI storage down-arrow, *BUT* the actual block devices have trim/discard plumbed all the way through the stack, so removing files from an AppVM does indeed free the unde
<jpo>
err, idk if IRC/matrix/whatever will truncate that. splitting into two parts because it's 2020 and we still can't have reasonable chat:
<jpo>
oh yeah, and about the space consumption issue: i suspect you might be misinterpreting what's going on. you can't easily "shrink" the allocated space as in `qvm-volume resize ...` (actually... you can, even safely, but only after manually shrinking the fs in the guest first) or via the settings UI storage down-arrow
<jpo>
*BUT* the actual block devices have trim/discard plumbed all the way through the stack, so removing files from an AppVM does indeed free the underlying sparsely-allocated storage of the underlying storage medium and reclaim capacity to be used elsewhere
<jpo>
if you're experiencing something different (possibly on a non-LVM storage pool?), then that's a bug, and you should file an issue
* jpo
really goes back to perpetual idle
<jpo>
pie_: updating the pitchfork looks to be possible directly via jtag, and updates controlled via stm32 "secure boot" mechanism. this probably means rollbacks are posible, because the ST SFU mode seems to just do version checks online in running trustzone firmware rather than having some secure non-volatile monotonic counter in hardware
leah2 has quit [Remote host closed the connection]
leah2 has joined #spectrum
<ehmry>
jpo: we talked about tracking nixos issues, security reporting, and i gave a genodepkgs update
stigo has quit [Ping timeout: 272 seconds]
cation21- has joined #spectrum
cation21 has quit [Ping timeout: 260 seconds]
cation21- is now known as cation21
stigo has joined #spectrum
cole-h has joined #spectrum
<qyliss>
Quick update for people wondering what's going on:
<qyliss>
I'm negotiating with NLnet to enable me to carry on working on Spectrum for longer. Things looking pretty positive there.
<qyliss>
While crunching to try to hit a milestone, I made a lot of progress after writing the last TWiS. Inter-VM networking and USB and filesystems are functional, and I've started writing a program that sets all this up when starting a VM.
<qyliss>
However, I'm extremely burnt out and need a break, because I'm really struggling to keep going atm
<qyliss>
So the plan is this:
<qyliss>
1. Make sure funding is secure for when I'm back from the break
<qyliss>
(and that I have enough money immediately available to be able to fund the break, which should be fine as long as GH sponsors income holds while I'm on break)
<qyliss>
2. Write a big update to the ML with everything that's happened since I stopped writing TWiS
<qyliss>
3. Take break. Probably a couple of months or so.
<qyliss>
4. Return and carry on.
<qyliss>
At that point, I'd expect TWiS to come back. It's on hiatus first while I was crunching and now while I'm burnt out, but it will be back.
<pie_>
\o/
MilkManzJourDadd has left #spectrum ["User left"]
<qyliss>
Oh also, I commissioned a Spectrum logo because people kept asking
<qyliss>
So I'll introduce that in the big update too
<qyliss>
it's very neat :)
pinkieval has quit [Ping timeout: 260 seconds]
pinkieval has joined #spectrum
<cole-h>
<3 qyliss
<cole-h>
When you're back from the burnout-break, I hope we can do a stream again sometime. Those were fun and interesting.
<qyliss>
Yeah I miss those
<qyliss>
I'd like to show off the new VM plumbing program on one of them
<cole-h>
I'm a little sad it will be a few months until it happens, but I can't wait!
<cole-h>
Enjoy your break :)
<qyliss>
I might end up getting bored during the break, you never know ;)
<cole-h>
:D
<hyperfekt>
i'd rather it be completed than abandoned earlier ^^
<hyperfekt>
qyliss: take your time <3
<multi>
qyliss: well done on the progress, take your time with the break
<multi>
you sound like you have some well-earned time off waiting for you