Re: [qubes-devel] GitHub ticket #5929 disappeared (official Arch Linux template)

[Rusty Bird]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

Marek Marczykowski-Górecki:
> On Wed, Apr 20, 2022 at 12:32:56PM +0000, Rusty Bird wrote:
> > Did you ever hear back from them?
> 
> Yes, a month later, and it's not very optimistic one:

> I'm unable to provide any further information about this for privacy and
> security reasons [...]

Classic

> Technically, the historical aspect of it isn't huge issue for us, as we
> try to not trust github too much (which includes having enough context
> in commit messages, having backups of issues, having notification email
> history etc). And honestly, I find searching through email notifications
> way more reliable than github's built in search.

Email notifications include the comment ID:

| Message-ID: 
| [...]
| Reply to this email directly or view it on GitHub:
| https://github.com/QubesOS/qubes-issues/issues/7359#issuecomment-1086681239

Maybe GitHub's GraphQL could be queried to list all comment IDs etc.
for comparison - and to monitor if things are getting worse.

> PS I have used gitlab.com recently in another project, for about 2
> years. The project was _much_ smaller, in terms of number of issues,
> repositories count, contributions count, length of discussions and
> pretty much any other metric. And the subjective feeling was: gitlab is
> incredibly slower than github and much less stable.

Also: gitlab.com often blocks me (or probably Tor users in general)
from even seeing CI results unless I log in, boo

Rusty
-BEGIN PGP SIGNATURE-

iQKTBAEBCgB9FiEEhLWbz8YrEp/hsG0ERp149HqvKt8FAmJgKttfFIAALgAo
aXNzdWVyLWZwckBub3RhdGlvbnMub3BlbnBncC5maWZ0aGhvcnNlbWFuLm5ldDg0
QjU5QkNGQzYyQjEyOUZFMUIwNkQwNDQ2OUQ3OEY0N0FBRjJBREYACgkQRp149Hqv
Kt/NCg//V2/jxthTm6pGlddelA6THfA31xPSvb6aIzrRGk6NVq6avAo2d5J55e0n
5eMUnxxJ44yRk0C6jgzlyUw//Ag4BMreggbe23QoQx4Z+AW/xKBL9FZnnE+jvRB+
i+oJ4Hpv49KGm+5X3FvwwrXYAo603lS0GYDpgUbqCJm9jkju2R1HGum42kiTs2b5
qODphhGEKmC1aaljmdEW2y4ptbLdo/zNnZX+OKXjwS0vtPAg8DDx6NzOxvhnZl8q
8xw9ns0jW0a77qOHqDbn6T5kyawV9KDbck3IBLO+bQeiOU6wQ1OlosYFEnn1w7BH
OdPp1EuFQr2dfAJzknh6MLULUSciovHKgABQ+KovCv/sLgP84Wci5dR6HAZJLhip
1c3RZdLE/2prgPEnDohp4aJ+IozAiXYJhhT44WFn/es/vI2ddnqoo/nE3v0sCokc
Ukuvn3pyj0iXqCiZxmawGJkJ661DIYmSBIs6o/JZHTl2GGx/SG/2TEgRcqMnMP0n
S6vOMSYmH8bmkkiAimmvXa8hQGDP49uwGexeoHU9VAvRGUfqnxxp/OvId1XpDuuJ
DnkcxPvdha3kRGRRAz62x0G0aPKU6LexX1PU6kz15qgFJppiHDOlGikiadfWJSe5
4dFWAR+RDWfiEmAZ3w1+vJimiMcLLOfIftO8cPjchy8/lewG56A=
=lyS3
-END PGP SIGNATURE-

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

Re: [qubes-devel] GitHub ticket #5929 disappeared (official Arch Linux template)

[Rusty Bird]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

Marek Marczykowski-Górecki:
> On Mon, May 10, 2021 at 11:56:51AM +0000, Rusty Bird wrote:
> > Marek Marczykowski-Górecki:
> > > On Mon, May 10, 2021 at 10:27:38AM +, Rusty Bird wrote:
> > > > I was trying to check on the status of the Arch Linux template, but
> > > > the issue ticket[1] has disappeared ("Page not found"). Maybe it's
> > > > caught in a GitHub spam filter?
> > > 
> > > Likely yes, for some weird reason. I've asked github support to restore
> > > it.
> > 
> > After a couple of GitHub API requests, it looks like they're currently
> > memory-holing 43 issues:
> 
> Thanks for the list. Based on it, I've searched the github export I do
> from time to time, and I can confirm most of them are not spam (at least
> looking at the title, haven't checked the body).
> Specifically this list:
> https://github.com/QubesOS/qubes-issues/issues/1004
> https://github.com/QubesOS/qubes-issues/issues/1017
> https://github.com/QubesOS/qubes-issues/issues/1025
> https://github.com/QubesOS/qubes-issues/issues/1127
> https://github.com/QubesOS/qubes-issues/issues/1510
> https://github.com/QubesOS/qubes-issues/issues/1678
> https://github.com/QubesOS/qubes-issues/issues/1794
> https://github.com/QubesOS/qubes-issues/issues/2196
> https://github.com/QubesOS/qubes-issues/issues/2221
> https://github.com/QubesOS/qubes-issues/issues/2669
> https://github.com/QubesOS/qubes-issues/issues/2804
> https://github.com/QubesOS/qubes-issues/issues/2862
> https://github.com/QubesOS/qubes-issues/issues/3119
> https://github.com/QubesOS/qubes-issues/issues/3272 
> https://github.com/QubesOS/qubes-issues/issues/3358
> https://github.com/QubesOS/qubes-issues/issues/3395
> https://github.com/QubesOS/qubes-issues/issues/3402
> https://github.com/QubesOS/qubes-issues/issues/3414
> https://github.com/QubesOS/qubes-issues/issues/4037
> https://github.com/QubesOS/qubes-issues/issues/4056
> https://github.com/QubesOS/qubes-issues/issues/4107
> https://github.com/QubesOS/qubes-issues/issues/4108
> https://github.com/QubesOS/qubes-issues/issues/4240
> https://github.com/QubesOS/qubes-issues/issues/4605
> https://github.com/QubesOS/qubes-issues/issues/4690
> https://github.com/QubesOS/qubes-issues/issues/5033
> https://github.com/QubesOS/qubes-issues/issues/5083
> https://github.com/QubesOS/qubes-issues/issues/5154
> https://github.com/QubesOS/qubes-issues/issues/5204
> https://github.com/QubesOS/qubes-issues/issues/5205
> https://github.com/QubesOS/qubes-issues/issues/5325
> https://github.com/QubesOS/qubes-issues/issues/5334
> https://github.com/QubesOS/qubes-issues/issues/5582
> https://github.com/QubesOS/qubes-issues/issues/5928 
> https://github.com/QubesOS/qubes-issues/issues/5929 
> https://github.com/QubesOS/qubes-issues/issues/6415
> https://github.com/QubesOS/qubes-issues/issues/6422 (dupplicate of 6415)
> https://github.com/QubesOS/qubes-issues/issues/6451
> https://github.com/QubesOS/qubes-issues/issues/6452 (dupplicate of 6451)
> 
> That said, many of them are misplaced and were immediately closed as
> "invalid" as they should be rather posted to forum or ML.
> 
> I'll add them to the list in github support request...

Did you ever hear back from them?

I just read something disturbing that might be relevant:

| Apparently, “suspending an account” on GitHub actually means *deleting
| all activity for a user* — which results in (1) every pull request
| from the suspended account being *deleted*, (2) every issue opened by
| the suspended account being *deleted*, (3) every comment or discussion
| from the suspended account being *deleted*. In effect, the user’s
| entire activity and history is evaporated.

| All of a sudden, I was seeing pull requests, issues, and comments
| disappear from users who were actively contributing to the project.
| *We lost valuable contributions, information, context, and discussion
| history* on issues and pull requests. We even lost pull requests that
| were open and under active review. That work is now entirely lost.
| Gone forever. For pull requests that _did_ merge, we have the raw
| commit history — but that is not a substitute for a full code review
| and discussion.

https://www.jessesquires.com/blog/2022/04/19/github-suspending-russian-accounts/

Rusty
-BEGIN PGP SIGNATURE-

iQKTBAEBCgB9FiEEhLWbz8YrEp/hsG0ERp149HqvKt8FAmJf/XhfFIAALgAo
aXNzdWVyLWZwckBub3RhdGlvbnMub3BlbnBncC5maWZ0aGhvcnNlbWFuLm5ldDg0
QjU5QkNGQzYyQjEyOUZFMUIwNkQwNDQ2OUQ3OEY0N0FBRjJBREYACgkQRp149Hqv
Kt+xcA//ceynKL9MVTNmGtkeDMT0rqRUBBMAY242ZPnNp5MrXKd4/mJZql1rARdT
l/fdHX4/i/sts5zvd14xa277MbwFbqAAO9kT7HDahojf3FZGEY8OIoFDCdZ+jkdb
zU5YWjtlFqFGbSgJyhSn2zMoIFjkYn3W62ecGAZxtJgbxaHpmpnejuTYvEyTqRPl
J

Re: [qubes-devel] Distributing OS-specific Changes

[Rusty Bird]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

Hi David,

> How do you distribute modifications specific to certain template operating 
> systems?
> 
> I considered sending the seemingly trivial 2-line PR for [5988], but then 
> noticed that
> modifying upstream systemd configuration can be done in many ways with each 
> having Pros and Cons and none seeming straightforward:
> 
>  1. Maintain an own systemd package for 2+ distributions:
> Oh no, I'm a simple man... This doesn't scale well.
>  2. Add it to the builder process as 40_*post script or so:
> The next time an upstream maintainer changes the modified lines, we're 
> back to the maintainer state.
>  3. Use dom0 salt:
> Similar to 2. unless one does it after every update. This would however 
> force users to update their OS via salt for the optimal experience? Not great 
> - I like my "apt-get dist-upgrade".
> It might be Okayish for this particular change as the configuration is 
> almost never touched by upstream.
>  4. Maintain some distro-specific code that is called after every update:
> Quite a project by itself & another maintenance burden, but probably 
> scales better than 1. A quick look however led me to the conclusion that e.g. 
> for apt the callbacks are all quite shaky and pass little information to the 
> called script (nothing about the executed action for example).
>  5. Some hopefully obvious solution that I missed?
> 
> [5988] https://github.com/QubesOS/qubes-issues/issues/5988

This is about the watchdog thing? You could add another[1] systemd
"drop-in"[2] file - systemd-logind.service.d/30_qubes.conf - to the
qubes-core-agent-systemd package, containing

[Service]
WatchdogSec=0

1. https://github.com/QubesOS/qubes-core-agent-linux/tree/master/vm-systemd
2. https://www.freedesktop.org/software/systemd/man/systemd.unit.html

Rusty
-BEGIN PGP SIGNATURE-

iQKTBAEBCgB9FiEEhLWbz8YrEp/hsG0ERp149HqvKt8FAmDN0wdfFIAALgAo
aXNzdWVyLWZwckBub3RhdGlvbnMub3BlbnBncC5maWZ0aGhvcnNlbWFuLm5ldDg0
QjU5QkNGQzYyQjEyOUZFMUIwNkQwNDQ2OUQ3OEY0N0FBRjJBREYACgkQRp149Hqv
Kt8WGw//VNTs/Asu2bkO29xK/bV/zlDGqfENBy7+l7fBIGYsWG3Va5hfHWjHal6I
PujNgBCqIFH9OtDOEK0hpGgX+f94HgQ690e8igqnxqE4EiajuYtY6e7izZZuvMYM
nAkxjHdvh+nAt7EAG+fxqyN227OPhHZ+3NxkWEhy/yh/eak6SKpCHJDUij1yStZK
jT25z8SwGuTv4SqgXKcK5wdAvvDmE4ciSJj45SSL8rLt87cBXWiTznzxPGsHzePn
BvRmO+MFFSbKMOmVm+9d8V1ZU16Ee76Q7bDAPvdgiTIUPoSkW1Y8V3lp6YFfhLnn
xD7VD78NEb8Pf4/b65dhgV+L3CaA+Fdqoqby+uLfCNmBRn6z+PNYfqdu7BNIf0yV
Zwt7LeQbP+ExETxiV93qbFzWiDdDqgUlkF3AD/YvGVtW3+0to49+XAtN+EAaqdaZ
MwBH4OcA7NvqUBZ9ZRoDFgJdTUH3T2UTdIwf2Hn7WSMcZxlBJb0vNlDxZdl8WakD
xQrTYmCYbhHS6CPqA0BF6PLYD+eRwi8HbapbBsUijUtaPd+/R+zMzcba7bBerRz2
6SMA0QGCluWKJTS6dnyJBF0tgCOJiGGjtNCUGw7bCY61JwmuLwXLxPe+t51R086p
9cmqLhJzRKFl2/pGm5dP7gWpChi4vWmaeFDeufh8ZP3Hqlq+Nzw=
=+NKQ
-END PGP SIGNATURE-

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

Re: [qubes-devel] GitHub ticket #5929 disappeared (official Arch Linux template)

[Rusty Bird]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

Marek Marczykowski-Górecki:
> On Mon, May 10, 2021 at 10:27:38AM +0000, Rusty Bird wrote:
> > I was trying to check on the status of the Arch Linux template, but
> > the issue ticket[1] has disappeared ("Page not found"). Maybe it's
> > caught in a GitHub spam filter?
> 
> Likely yes, for some weird reason. I've asked github support to restore
> it.

After a couple of GitHub API requests, it looks like they're currently
memory-holing 43 issues:

https://github.com/QubesOS/qubes-issues/issues/1004
https://github.com/QubesOS/qubes-issues/issues/1017
https://github.com/QubesOS/qubes-issues/issues/1025
https://github.com/QubesOS/qubes-issues/issues/1127
https://github.com/QubesOS/qubes-issues/issues/1510
https://github.com/QubesOS/qubes-issues/issues/1678
https://github.com/QubesOS/qubes-issues/issues/1794
https://github.com/QubesOS/qubes-issues/issues/2196
https://github.com/QubesOS/qubes-issues/issues/2221
https://github.com/QubesOS/qubes-issues/issues/2669
https://github.com/QubesOS/qubes-issues/issues/2804
https://github.com/QubesOS/qubes-issues/issues/2862
https://github.com/QubesOS/qubes-issues/issues/2898
https://github.com/QubesOS/qubes-issues/issues/3119
https://github.com/QubesOS/qubes-issues/issues/3272 *
https://github.com/QubesOS/qubes-issues/issues/3358
https://github.com/QubesOS/qubes-issues/issues/3395
https://github.com/QubesOS/qubes-issues/issues/3402
https://github.com/QubesOS/qubes-issues/issues/3414
https://github.com/QubesOS/qubes-issues/issues/4037
https://github.com/QubesOS/qubes-issues/issues/4056
https://github.com/QubesOS/qubes-issues/issues/4107
https://github.com/QubesOS/qubes-issues/issues/4108
https://github.com/QubesOS/qubes-issues/issues/4240
https://github.com/QubesOS/qubes-issues/issues/4605
https://github.com/QubesOS/qubes-issues/issues/4690
https://github.com/QubesOS/qubes-issues/issues/5033
https://github.com/QubesOS/qubes-issues/issues/5083
https://github.com/QubesOS/qubes-issues/issues/5154
https://github.com/QubesOS/qubes-issues/issues/5204
https://github.com/QubesOS/qubes-issues/issues/5205
https://github.com/QubesOS/qubes-issues/issues/5325
https://github.com/QubesOS/qubes-issues/issues/5334
https://github.com/QubesOS/qubes-issues/issues/5582
https://github.com/QubesOS/qubes-issues/issues/5812
https://github.com/QubesOS/qubes-issues/issues/5924
https://github.com/QubesOS/qubes-issues/issues/5928 *
https://github.com/QubesOS/qubes-issues/issues/5929 *
https://github.com/QubesOS/qubes-issues/issues/6344
https://github.com/QubesOS/qubes-issues/issues/6415
https://github.com/QubesOS/qubes-issues/issues/6422
https://github.com/QubesOS/qubes-issues/issues/6451
https://github.com/QubesOS/qubes-issues/issues/6452

* Available on archive.org:

https://web.archive.org/web/20201019233532/https://github.com/QubesOS/qubes-issues/issues/3272
https://web.archive.org/web/20201020010613/https://github.com/QubesOS/qubes-issues/issues/5928
https://web.archive.org/web/20201020010612/https://github.com/QubesOS/qubes-issues/issues/5929

Rusty
-BEGIN PGP SIGNATURE-

iQKTBAEBCgB9FiEEhLWbz8YrEp/hsG0ERp149HqvKt8FAmCZH4NfFIAALgAo
aXNzdWVyLWZwckBub3RhdGlvbnMub3BlbnBncC5maWZ0aGhvcnNlbWFuLm5ldDg0
QjU5QkNGQzYyQjEyOUZFMUIwNkQwNDQ2OUQ3OEY0N0FBRjJBREYACgkQRp149Hqv
Kt+YEQ/9FQpQ27lwrBnBV6La00lfMpbgb1m2JmUZiPRE1wfuGRrq/qy96GIYTxoy
B6GLmzdTRT4dZO9CvJR+mMi5AJpRgwXrYWi7XsvouZxgmRzfMRQiGMlaT/6KXxhb
q6w4ptTolUGEY2rccQnW06IMugyU3FcOgpEhbDipQ6q69B0m/PKe7AJtOS6Uxad7
6TX/wQfspZJgJSU0EuYLs12HCqEmFNGMClVmZR1ybM+JueZ+rUbnD643ZLqm68JE
BpJZr4VTNQvo+yxeHHUALPiYMz84fysb7FX3aD8CQzZNLF/BsEYlhCykt/X5RXQo
5tJkknhGzZ/5+1SrV3sCIs3KcIz7/U1BS4j1hrblDr6GiW805/m9uB/sAKhqw5GH
9D2lQDd/jglNbP6x+Zb50P5OuFyTdSe/q70chbl9cP193A6A8ZbQ2dtHeaoSr/eK
YneIb5oUhU5qCzeqN31UVYDtqtlYQ/aN1/UtuU44D72vTGEQl9KNmgbdKh3V+Efe
YiGuQVJI5q2rFfhKx5Sn55ef0OlTYcURvS3ubRNt/xI4sbC/5SPivQvciSHEL7Fs
9NmqV2cLCASkhKj4Q2GYhEeRPSbtLdPvJuDvWMVDND+Zhwj80kNBclCO8Ex03j6U
Pu46rPh7CizfKH1K8JkwP61BqxwA0HxdUsVrI1zlD3sN4pVEtZs=
=b+rm
-END PGP SIGNATURE-

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

[qubes-devel] GitHub ticket #5929 disappeared (official Arch Linux template)

[Rusty Bird]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

I was trying to check on the status of the Arch Linux template, but
the issue ticket[1] has disappeared ("Page not found"). Maybe it's
caught in a GitHub spam filter?

(archive.org has a single old capture[2] that's definitely missing
some updates.)

Rusty

1. https://github.com/QubesOS/qubes-issues/issues/5929
2. 
https://web.archive.org/web/20201020010612/https://github.com/QubesOS/qubes-issues/issues/5929
-BEGIN PGP SIGNATURE-

iQKTBAEBCgB9FiEEhLWbz8YrEp/hsG0ERp149HqvKt8FAmCZCplfFIAALgAo
aXNzdWVyLWZwckBub3RhdGlvbnMub3BlbnBncC5maWZ0aGhvcnNlbWFuLm5ldDg0
QjU5QkNGQzYyQjEyOUZFMUIwNkQwNDQ2OUQ3OEY0N0FBRjJBREYACgkQRp149Hqv
Kt9unw/+MCFvFppc/iy0icFNP8yiSynwgce8RPBMqs6U2zErIGBbP10zmsakot7f
QmsBTciaabCD/wfV8U4IRI1AD5nJz6ZiLnVlYNJjbI7Nd8/2cyI5qg4rOXtg0Fm4
RMM7mGqajbhl4iJ+DV1jmcfTrqG5hGL8mzkX55UTyE/GheElnLUN0PeI2cYCXnd1
JEUOoo3QC0gjstkRMetWACXKNd/w7VPnR2u/gf2LyxcQsMfQ0YM7d2DDKKUDxzlX
ohELDFJvVNRpFYU5JfiPIwwPtqGn3QlO0qME8sxM+zVn5QANJGy4H0wS9y/vBM3o
Uo91wy+WBoS1eGnnwEKPQT0Xab+wL0Iri4zYf7yEM0a2fBCrCj9XCcSSO+iBfbLo
jqrfpZN8u9/K7ym9jAYQTl11GDRC8bHZH2rYWx8sxOwO9WGMEo4nvxsi9eMnH7l7
c9iHRKtUgUik3OqmrWZ2Toa6/yK5zFziRFgtq3qgpT+/HMSEC06GdkgYiB15DU5n
2WsLRYgUEwavjkR7GMQ4G7iz2BiFSLycOz/YEKpmbpD+lNPG1p554emSew+sb2Mp
AFemSgnYifSsYyNsZ1F/Bk1MdBY3gH95+x++PwuPJKyvp5YtWtUIgFmP2dm+QmAY
SS/QNicKORByaGy+NEIpUUZgYrc5HQwzmIw2+0wJ4hj6LHRcwYc=
=lHm9
-END PGP SIGNATURE-


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

Re: [qubes-devel] Addressing the long shutdown time with LVM thin volumes

[Rusty Bird]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

Peter Todd:
> On Fri, Feb 05, 2021 at 06:59:05PM +0100, donoban wrote:
> > On 2/5/21 5:24 PM, Jinoh Kang wrote:
> > > - Switch to reflinks. BTRFS has been around 10+ years, so I assume it's
> > >   stable enough?
> > 
> > I've been using BTRFS for a few years now and haven't had any problems
> > except some CPU bottleneck using send/receive, but probably you are not
> > interested in that functionality.
> 
> I'd like to see btrfs added for its checksums as well. I've personally had
> `btrfs scrub` catch hardware problems before more data got silently corrupted.

It's not the default, but Qubes already supports this since R4.0.1:

If the Btrfs layout is selected (instead of LVM Thin) during Qubes
installation, a 'file-reflink' storage driver pool will be created
automatically.

Rusty
-BEGIN PGP SIGNATURE-

iQKTBAEBCgB9FiEEhLWbz8YrEp/hsG0ERp149HqvKt8FAmAlDtpfFIAALgAo
aXNzdWVyLWZwckBub3RhdGlvbnMub3BlbnBncC5maWZ0aGhvcnNlbWFuLm5ldDg0
QjU5QkNGQzYyQjEyOUZFMUIwNkQwNDQ2OUQ3OEY0N0FBRjJBREYACgkQRp149Hqv
Kt/RhA//QoMuAJEGB4P7np2wbJ2YP2noR8puPPgAlxpZ7o9ZsgQVOMH4rn/O03fz
YJoVYxaOIxEttjRvZa2trjTcM0zWlxgnVKXkio11rMFACLkJJb5bICtUri77ynFM
O8aUI8VgY5erI8zivP0H9NlWi/I93cgd8TFEJjlgLgPlIs22NzhfCrmbIy5Pa/SL
ppW/mn+v6hzvsIII9fwj8Dv3meDVS/0UTjpeAWjizPaIX41DIZwtUbwfw/wxsHWm
CzIVQKC/jRsgFjc66WsGvK+L0Sg4zwtKjJBjexTRhsoYvejoGPn6vq8kXCXk8Qt6
QR841VKgyV+svqx0muZTaibTW/bIHI09mjAkJpuPerPGSaobBZ2dOmYIZRpkTHQb
WWnTrLfP3onWPQMrGmKiXBP/2o07i91AU6aOVjn6UfHcdVzISHdLUB4EaKVgoXpb
UU1VtON0oNEhvoRHO62lEdbbIkdA1abAYLYiHb5BfS3kdUcf3qJcKw1R7IxngWf0
qDoz7SCgwhDMwGweglH57mFvqUBFvMqIVmkWLZ9oL7iIivb+ke3zvH5HZR9x7w81
/O6fSW4b2NQeBPE0RjiqrQnV67PsLOF3QG7+asUl53u3zUnBIuNoD+PFCuiVvgnF
aKGnFZHsWxBAwVxpZ28tFK3D8BQpYKgChxsHN9E+MQSG8+XynI8=
=7V+3
-END PGP SIGNATURE-


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

Re: [qubes-devel] "Make an Alpha!"

[Rusty Bird]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

Marek Marczykowski-Górecki:
> Nest week turned out to be next month, but it's here:
> https://ftp.qubes-os.org/iso/Qubes-R4.1.0-alpha20201014-x86_64.iso
> and its signature: 
> https://ftp.qubes-os.org/iso/Qubes-R4.1.0-alpha20201014-x86_64.iso.asc

Yesss! And congrats on slaying that hydra of Xen S3 resumption bugs.

Rusty
-BEGIN PGP SIGNATURE-

iQKSBAEBCgB9FiEEhLWbz8YrEp/hsG0ERp149HqvKt8FAl+HOGZfFIAALgAo
aXNzdWVyLWZwckBub3RhdGlvbnMub3BlbnBncC5maWZ0aGhvcnNlbWFuLm5ldDg0
QjU5QkNGQzYyQjEyOUZFMUIwNkQwNDQ2OUQ3OEY0N0FBRjJBREYACgkQRp149Hqv
Kt8QjA/3bQ3RVx1VftdgzWazecaQI6uPPLKvEfyK2EmNTh9I5VoKy4VGXin5Hx2K
HmTKYLQVPBVQOc+9n3HI34ckrINWtk2OwTuc+Uh1bmo5tI/VPDzaZHFdtbIjTTgH
IB2BYGMIblT4XNwfQXLaeD58kzW+8RPpPnh13cNzZ/G0p11CROWTeklwMGRDePUH
apioIEB4CeVfsq8aFEU8SjrSnLiHILBzMHyco9gH13NoRVN7f3g+oZLzGdSC8Wlp
kPQr/dPBLrOM/TH3BHYG8asp98ZyxocxMm8Jzn3ARY+lQ5FQMjt/iLtUMEDZ/A4r
b7G6XcnWCfx+Bb9NdKkOVowf9mDABoJ6iwaD/dGBNDbNowo2BsB407wfO0A2RjwL
EUHxLHTQEmR97pzNU5fVd0rJgXdqq9MytlwGDxAgBEyxwuSRtuC8N9+ZX80eerRE
grjdPxumPhXBUHlFdTyYucL8MHATwsjinM2cYwzqSJYnspB7LvIftpWSh32+ufxz
WEwmrA27JkZXGyZ3gd+l/+Wro4Mw1YYA43e8sauvLWM5ZrpJaQYb8E6r+RqUkidP
19vHrIRDiGVsPbQypT986/Ty5gqGR84Bmgus0cgeo/9SqTTbfOkdpH4ougGogrVm
/o28wdu6dWwLQwejKhCa0N5y3t6Mh3Bm9CaIg5y4i8gvMECihQ==
=rV3o
-END PGP SIGNATURE-

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

Re: [qubes-devel] "Make an Alpha!"

[Rusty Bird]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

Chris Laprise:
> On 9/20/20 3:10 PM, Rusty Bird wrote:
> > Chris Laprise:
> > > * Allocating a thin lvm pool and then using the plain file pool type
> > 
> > Can you expand on what you're trying to do and how it's going wrong?

> In the GUI, I choose my keyboard layout, then I click on the Install
> Destination icon, leave it on automatic, click Done then enter a luks
> passphrase. Next it says I need more space so I click on Reclaim Space and
> then the Delete All button. Finally, I choose User Creation and give it a
> simple user name+pwd.
> 
> The result is that Qubes domUs are using qcow image files, despite the
> installer having setup lvm with a pool for root (which is being used by
> dom0) and a large lvm pool for domUs (which is NOT being used at all).
> Installing templates and creating new vms creates img files in
> /var/lib/qubes (i.e. using the small root volume).

Hmm, I just tried Qubes-4.1-20200914-x86_64.iso from openQA and also
clicked through Reclaim Space -> Delete All. But here it succeeded in
using the LVM pool for everything.

Rusty
-BEGIN PGP SIGNATURE-

iQKTBAEBCgB9FiEEhLWbz8YrEp/hsG0ERp149HqvKt8FAl9pA9NfFIAALgAo
aXNzdWVyLWZwckBub3RhdGlvbnMub3BlbnBncC5maWZ0aGhvcnNlbWFuLm5ldDg0
QjU5QkNGQzYyQjEyOUZFMUIwNkQwNDQ2OUQ3OEY0N0FBRjJBREYACgkQRp149Hqv
Kt+efg//aKPmxy9la3LLMqdEgeel+FIGbWFx4k+nVkqvtVg4Cn2VUaepH5HCgB21
GZuhUzE1H3KILbVVEX4JUd7HnUx4DQWyhAfVrET8c4iGfit/CAgEBq4miAP0avRH
4JrG07uNV285cDcW6+ybzBUAlxyQKDoSDm7aLb5/oVOEu62+SFW7o37jPAJXM2Tn
qWsTbca18R0JlroP/c5Fn4urZFt7OP0cyCQOYtP11Nu3MODhIuNQeieZPiE9axDd
04S0w3om2Vwt8GOxh6BBWke2+vSvEsz9kEiaeeNTUJABVlRTcv7IRC2o4fuMpgQR
Yi2Iq7gtENYhOIc/nIzdQ+cU99kCWpVtKTj73VfHnyRvIzaK+azXzRXWtuPJDR9J
6UcIVZlEJ8nGdTad/m/mKSO5CuOY+QYo+lw/HPMUJTslPPA9AD1DSpoGsdsNfPdy
8OCY7Ryi3XiEDl8rqS3e7PDw+VGC9Jq38G+3nif1uVMcMP1Z5wt4HYXKJEzP/B7v
ysuKV8ORX1tqzVCFqkJ8JmHbSoeGEgzehpHbgqZFd6ks8qygfTwM42JH3D1Ww2Ee
TerNEdWl4m0aITLXUDqal/b+1m/7aaFTuPudXR26hydrigvlCFPjY42eC+j8GuUX
aTR1UM5VORorzlfGMSdm+Cq73d/a+o1YAIVjP6/CV3xv8vNmXqw=
=I6om
-END PGP SIGNATURE-

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

Re: [qubes-devel] "Make an Alpha!"

[Rusty Bird]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

> On 9/20/20 2:03 PM, Marek Marczykowski-Górecki wrote:
> > In the meantime, I could use some help with debugging suspend issues[2]
> > which I consider one of the very few blockers before I switch to R4.1
> > myself :)

Oh shit, I'm like the least qualified person to help with this. I've
never even attempted to suspend any OS to RAM or to disk in my life.

Chris Laprise:
> * Allocating a thin lvm pool and then using the plain file pool type

Can you expand on what you're trying to do and how it's going wrong?

> * Incompatibility with a popular Intel wifi card

AX200? Then at least it's not a regression from R4.0.3.

Rusty
-BEGIN PGP SIGNATURE-

iQKTBAEBCgB9FiEEhLWbz8YrEp/hsG0ERp149HqvKt8FAl9nqUJfFIAALgAo
aXNzdWVyLWZwckBub3RhdGlvbnMub3BlbnBncC5maWZ0aGhvcnNlbWFuLm5ldDg0
QjU5QkNGQzYyQjEyOUZFMUIwNkQwNDQ2OUQ3OEY0N0FBRjJBREYACgkQRp149Hqv
Kt+DuA//W2vLfIA3LFX+xyNWXJSMkRAOYJv/xhH4E0b+DcjJR1LiHgXeylCIt4RL
u0VLqqAgS5bRIi33DrAvlpxKbkNRWaQp8CsJDxn1G06wTfFvCN6NsPKP81nEgFq8
aEJo8LXZdc9rs7CBAgnTXBYe1LfhJB711pDKJcsVysHOFDH1jbJwM/vvxGBOUFPU
ycJzvY0/AlOolrC7rTEBw4RTFPzcxajdaIH/3p+2IkVD3y10OnRy3Ie56dEyYTAT
+F32N2/Sxqiq/9kP9NQVP1GfqYW1l8I2YpT9gzs+WRCmlMK5kjZBl98I9xT8iVNF
0DdGFV0PpRp/2spTwgqoP1U/aAw/Md+qaI9yxCvAGQT5zUnC/mBXqfQLaL8Zz4Lm
cAaw7hqTKwdVIDTTIaPFmSiwx9nxRuaDT3xk5m2H9/bV75BgzjCQuMEWIC9Sls0x
nbpeNrPoxFAI/yO7zw9umL4BOepl4bkzYCGu71s8b5+0tZakXP1nrb0BZqd/WVrM
zwW9RWeR63XvA6+SpidXh3jQI5wllBnJckuWWNLGbRwukbq3jezMpPUIpBtIZPjT
8XAe39r3Xf9+w1qeXxE9FbJ3/zbs6R/Eyn2L1GtXND2h2e2dTdpe3P/gskHH5Aso
RDD/xbgyraghC/aVYR/Voz0OjJm2M06ielR2/DKs9V8aDPXmXUc=
=rcss
-END PGP SIGNATURE-

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

[qubes-devel] "Make an Alpha!"

[Rusty Bird]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

Marek, the masses are chanting it!!
https://www.youtube.com/watch?v=sq5g-V63Q30=1511

Less shitpostingly, I was about to comment on #6041 with how to move
from ext4/file to btrfs/file-reflink but noticed that btrfs-convert
had a nasty bug that's fixed* in fc32. It would be bad to to encourage
users to boot untrusted openQA .iso blobs, so I'm just adding this to
the list of reasons why it would be neat to have a signed (pre-)alpha
R4.1 iso.

Rusty

* 
https://github.com/kdave/btrfs-progs/commit/0ff7a9b5210723bd4ad0d9d78dbbb18ee8fdd2b1
-BEGIN PGP SIGNATURE-

iQKTBAEBCgB9FiEEhLWbz8YrEp/hsG0ERp149HqvKt8FAl9nkmZfFIAALgAo
aXNzdWVyLWZwckBub3RhdGlvbnMub3BlbnBncC5maWZ0aGhvcnNlbWFuLm5ldDg0
QjU5QkNGQzYyQjEyOUZFMUIwNkQwNDQ2OUQ3OEY0N0FBRjJBREYACgkQRp149Hqv
Kt+06g//fAyvHV7zOyscHMruHqP0+3+2FGY0gJUMhr6+rOphKlsBx6NDP5rgFQxm
NFkJZzEhMcvJBJS+KYXCWHICqIXZjtzrD6zJBjKE9wl5OctOIHrjknTYt8yg6hYv
lXug+WBHHJo2gL2DT+EEms8Sd7hnPX5SErWO00g5nl7RTbT9UlY2vf+aFOZMRChV
HlsUgFPzw3XMnl5zmcWEoiOv6GU+xy91s8DOPS0hOW8UBNsxp6LlAelraIGof86h
jb1vT/zTvWxZ0J8BcLX9y/eDsFl4/aVoI1u9Si10wEaszzIJFKxPTgZ42CNTwPL+
GHLp6Cmm/K473JtL22BVqqna41b/c+6u6jVKx9PX05b4uyrxEiaHdCiJzCneEQGR
PyGyh8e3VSi5DPGSsD2XPkz9VXSf1Rr5UnbKqnJvxSY7iuDYbHWksI4Z/vYc8NdI
tZJ4gZkteBigsTOp4SCnerXuGkYh6OaT8MgB8Vu9PnFbDDLWBsh584vSo0oG5oyr
DU+UVg5Uo3GH685kE4vYVQlaaKx2GvjWL6jattKMJ+eEiWIOxqap1h4tMmGTfw6B
h+Sz/Ma/wCO5IJW3/fiI1D4lQrQd0FEGp41z6thj0byGFSbx/zMo8gHQU/IT44sr
UgffbCg4DTkxV6hvcDT8naTLtjLAcmLJJfa+xwG0VXc1alkVcYg=
=33ZD
-END PGP SIGNATURE-

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

Re: [qubes-devel] Take a snapshot of the Qube's memory

[Rusty Bird]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

Pin dev:
> I need to analyze memory from one qube that is suspected to contain 
> malware. 

$ xl dump-core vmname filename

Rusty
-BEGIN PGP SIGNATURE-

iQKTBAEBCgB9FiEEhLWbz8YrEp/hsG0ERp149HqvKt8FAl80Sl5fFIAALgAo
aXNzdWVyLWZwckBub3RhdGlvbnMub3BlbnBncC5maWZ0aGhvcnNlbWFuLm5ldDg0
QjU5QkNGQzYyQjEyOUZFMUIwNkQwNDQ2OUQ3OEY0N0FBRjJBREYACgkQRp149Hqv
Kt/mRw//Za+tsesPzOPXP1ZyNdX+I1JZQeN9iC5C0dWUaFhoQVVnlWD++8iWew8Y
Z9w11J9PIsSzErZAaZIivaOGFQyMZpdnP8+v34/ZznZAkl0Qoaw8eIKCN0KrLAgI
Qf7eSnHQL/4W4eMXu3baWjpKo/xHta8TJ/g7K/avCt8SPlUU6TZrGdSuqDggCe03
BbtejaQTyEdgV77xkbiBHbTRiq+/NBHIVtbCz1/WviBWGV3QJMqplJXUkCX0TT2a
02otO5W3Uc2iSy5Vvh5XdcWnzKib1OBe4TA2/QCBIxm9CCQ9DMRP3v5M41MfaYAz
my2UASaVF/VT1Pl+4JKFoUJ6dIKCFZ8aqQwWTnpZeUXYpktMRL3dusi06b7CJS6r
3IadwfRynGdXFbqGVUUwB6uSczst0PpwUfDEymGisdqhU639otzuQS2nBtTmF6nq
28WAzIK0/nx2ZZn3EGYI7thB5MJrGoZ/bF446Ht6WivfIsQyKt4pggSwF7rn5ggH
QJU1QZ57+BhtL+XOWXNL+5C/s3Q5R8UktTSYG2t60qbGjVUi/0C2Xtksvsx7PttM
VWwclkrWZF580rTWZzKg7kOLAGnNVHtjOiJVLO655UrHm6J8riWY9wlk5oiCaNvK
OCFpyuXlwIArJ1ZBWXikW1rQ1tywGlR2oVJY0GZBVvT9R3U4vO8=
=p+3S
-END PGP SIGNATURE-

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

Re: [qubes-devel] Pool interface questions

[Rusty Bird]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

David Hobach:
> I'm trying to understand the qubes.storage.Pool interface and its
> requirements for implementations.
> 
> In particular I wonder:
> Are implementations required to be fully initialized right after the
> constructor is called?

You don't necessarily have to do anything in __init__(), except
forward the call to the base class so it can set some standard
attributes like 'name'.

> For example, you usually wouldn't want to decrypt a pool until the user
> requests some data from it.
> 
> Or do I have to implement "lazy initialization" myself?
> 
> I.e. I guess I'd then have to one-time run the initialization code on any
> interface method that would require me to be initialized?

That sounds right. It's really up to the driver which of the public
methods - e.g. vol.remove() - can operate independently on a volume,
and which need to arrange some some heavy per-pool or global state.

Rusty
-BEGIN PGP SIGNATURE-

iQKTBAEBCgB9FiEEhLWbz8YrEp/hsG0ERp149HqvKt8FAl7mLAdfFIAALgAo
aXNzdWVyLWZwckBub3RhdGlvbnMub3BlbnBncC5maWZ0aGhvcnNlbWFuLm5ldDg0
QjU5QkNGQzYyQjEyOUZFMUIwNkQwNDQ2OUQ3OEY0N0FBRjJBREYACgkQRp149Hqv
Kt/9sg//aQ6ETqLucK+mvp+GfAhxZRxNzIgB4v+MsGwlNKkGZpKuwGtrjpEhNWnv
lBMhD0KyttKKwP7TGfospq6e8/s+3qJ4LMxJPJFbftWn1Y/Rd+nbsIbZzVONZ5bf
PCuImeD155RC+WKd0RZj+ZGgvToMe4ypESn3AUHIC2vB1MHVvTNMfbWnCzceZ7Bw
TUVY/iqkGnjNNZMunYUVcEe3tuUpt8y8k5NweoN7vR3cowfKBEH98FTotGTqucX8
MoCVgg/Q027KyhhU6EfvN7C+7dA+w9mT1N74Qw5UA6NzV287AjWBWIVR/8jTrgE3
6ZVD/QNy3o2+zbgmp70YWPoTKzEZxDFu2+uIIRVFb5nXnOal+ZIUysr6A0A5btZC
gk2jO0W+HXQJLO0HDfaB9k8aRxA3tH4/zPZsThay3RQCrXU9wg2d509aBE9txgSN
xbmMMyP4W9fwzXybvZBj9lvR0mT3Z496vqjUiK7PjgNsM5IlauZjm85xso5Rla5z
UnAEMPZ8+IZENRpB7NMNKx+JNX3SkbjiSys1UwVvLDLxiYSJ/oXLGpmBBQD/z6n8
6UD15ej55ov8qBK8Ahs/QdMj+3j6MRODy0Tauie+2EMkFmvIa5tOtM2dmmFLh4jJ
C2i8l1gC3Z9oHoKb6H9U4EnQi2VI4i5AjJkh3dUqYYGA2RKZoR0=
=GEWu
-END PGP SIGNATURE-

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

Re: [qubes-devel] socat dependency of qubes-core-dom0

[Rusty Bird]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

David Hobach:
> the latest dom0 update apparently introduced a socat dependency for
> qubes-core-dom0 4.0.47-1.
> 
> Where does this come from?

https://github.com/QubesOS/qubes-core-admin/commit/c95370c5fbb57c8fc6caadb6c20a1d4ef91e5369
https://github.com/QubesOS/qubes-core-admin/blob/release4.0/qubes-rpc/admin.vm.Console

Rusty
-BEGIN PGP SIGNATURE-

iQKTBAEBCgB9FiEEhLWbz8YrEp/hsG0ERp149HqvKt8FAl2tmktfFIAALgAo
aXNzdWVyLWZwckBub3RhdGlvbnMub3BlbnBncC5maWZ0aGhvcnNlbWFuLm5ldDg0
QjU5QkNGQzYyQjEyOUZFMUIwNkQwNDQ2OUQ3OEY0N0FBRjJBREYACgkQRp149Hqv
Kt9ysg/6Ah2+RcxJoFU7IuiLjQCxCU8BKDcGCaQVwHliq5MlWI4RNyj82U+eESZg
V52o5RCIxBJ+zx7yUR9Gt2rF53MvBu0cpsTrtl99KTRkZIfTFN45FUDx/Pk9A2LE
tzzKzb4sMDBRQSyMglVMcTYGWuJ+thqXwLk5BbzMO/Z9A/q/Msz1CypsuiT0c6Og
8h8U5Ebp9s/6euBWw6eyVMXWD5rXIfFLdpeFsVd9uLJHWAG3jXjsgXOtyuRSCC89
8AqKsTkfmDXDSi9C92fgK8nRrP3YfRZVeS9KrWBU7vUmH9A1fs9ZllA7oJINoL+s
qszAvF6C0tF4mSwRcVN+wCS0oSbC6GYdgYGgNk8MXx9+qvk7lS5SsVtaZZ1+EEfw
5PPiPII6SnfELauLz3d0NBuldMuWif/P0R3zj6CHei0jxtaHWZHgswzPWnmDCDVh
gTXT372r52qZFhgM+WQqdSZCKX+0YAkhDgyhVb14Fg1zgtAPaIuXm5AWTSQsCMxA
PLQMXy8x6wedCvK/T0Y0XPPDM/Ovs7qDotZVL7jS9xMmXTxvP4N0JfUtSllsRhP7
Y8IL6Xas3gLd0TiUyTyPvB31eLZjBtgpH4bbbQ3RurprsUFzMX/V05FU9wcz3E0f
OD6K4HvWhUXr+cEoSvCDZ/hwiV4Kx1xQfwLEHOlmLs+neYF5rNs=
=ixeU
-END PGP SIGNATURE-

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

Re: [qubes-devel] Re: Question about storage pool "file"

[Rusty Bird]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

Manuel Amador (Rudd-O):
> > I haven't been able to understand the codebase for the "file" storage
> > pool very well.

That might be for the better... It's kind of the haunted house storage
driver at this point.

> > At which point in the lifetime of a VM do changes get merged down from
> > the COW private.img to the base private img?

Never: In 'file', private.img stores the complete *up-to-date* data
(modified live if the VM is running) for the volume 'private', while
private-cow.img stores only the differing *old* blocks that have been
changed in private.img since volume start. commit() then just deletes
private-cow.img (if revisions_to_keep==0) or renames it to
private-cow.img.old (if revisions_to_keep==1).

Whereas in 'file-reflink' it's the opposite: private.img stores the
(complete) *old* data, and private-dirty.img stores the complete
*up-to-date* data.

> > If my machine crashes, what prevents the data in the COW private.img
> > from being lost next time the VM starts?

So this would not cause data loss.

But there are bound to be some serious data loss bugs in 'file' - the
worst that I know of is that cloning or backing up a running VM will
likely result in corrupted data (in the destination), because those
operations read the live volume data while it is being modified:

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

> my ZFS pool code

Nice. Godspeed!

I had been hoping that OpenZFS would finally get FICLONE support after
Or*cle ZFS got the Solaris equivalent a while ago - which would make
'file-reflink' compatible with ZFS. But nothing really seems to be
happening on that front:

https://github.com/zfsonlinux/zfs/issues/405

Rusty
-BEGIN PGP SIGNATURE-

iQKTBAEBCgB9FiEEhLWbz8YrEp/hsG0ERp149HqvKt8FAl0TQAFfFIAALgAo
aXNzdWVyLWZwckBub3RhdGlvbnMub3BlbnBncC5maWZ0aGhvcnNlbWFuLm5ldDg0
QjU5QkNGQzYyQjEyOUZFMUIwNkQwNDQ2OUQ3OEY0N0FBRjJBREYACgkQRp149Hqv
Kt8RdBAAifHE2iNVl4rK5DpPM3KxEqsEjHJRq/Ug2OE964jstspIZhGf+HRNrM49
iW7VuRi0RIiY15h0dX3AjYWdJJum237fnSC7XWzNpspjI4xpAUZKDBYufBAxqV8o
QvjLixpsI9LWNjBFOxld9ta50kkSrcWVt/0hbL1yGFaS5k+dXgfZsj1sjsb6WU9B
EjXviKeMINk68ee9YyXPZH9O5IRcZHH8S2OLzk7OO+eHUh70emEDqzNgDEFwZU1m
f1IA0REjcqPJK4r4rnkxtCWGYIcK3LH1iyeWk3/tOtoY0pZiytNux8q45owmStNS
h/VFp7RfKTsCIFk3tnG80jsr8i8VdaaQBDw5o9OBIAFkWNT04tI8O3BrJEUWrHRh
T9ffhdYce0szJtHx6X82onCoxMfkAadgdKxpYgu1Oq7C8wGKrfkarT0mCFuvaAoL
7UHbfcUF45ON/C8pbm4CEX8/EjFZbnAmyhVbYsPGUtDGKwEItltfn51SsFIDNnna
5DpZWtg8nIUPeVWy5wJ5NFZPstfsop1YC32PFXb5iPGJDC8EWZKMSdHygf2CG4KQ
POljOjlP+2Jr3cA9e2R9EMOobrkY5hBoax4phMPB5aeb77NOLor226neXE6P/zqf
13g90v391TIXbMJLLCtwL2ivJQ/FwPo1/Q5HZd7edmrkxRpaZaw=
=lXWr
-END PGP SIGNATURE-

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

Re: [qubes-devel] Build ISO from official uploaded packages?

[Rusty Bird]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

Marcus Linsner:
> On Thursday, September 27, 2018 at 7:15:30 PM UTC+2, Rusty Bird wrote:
> > Marcus Linsner:
> > > I haven't yet tried installing an .iso because I need to get an
> > > empty disk, probably next week, then I'll be back here with
> > > report(s) :D and re-read Marek's post/apply it...
> > 
> > Sure, no rush.
> I'm having second thoughts about using btrfs instead of ext4 now
> that it's the 2nd time that I've lost files on an Arch Linux laptop
> due to some btrfs-related kernel crash(oops with 4.19-rc5 now, in
> some zstd code). 

Ouch, that sounds stressful. By all means, stick to what works for
you!

> In both cases though it happened with -rc kernels, so I guess I had
> that comming :D
> [...]
> That commit=300 in fstab made things worse also.

Hmm ya, probably best to avoid the newest btrfs code and any less
common or aggressive options. FWIW, I've never had serious issues with
the LTS kernels, default mount options + noatime, and plenty of free
space.

> Maybe I should just do periodic snapshots

On Qubes, I've noticed that if there's more than a handful of whole-
filesystem snapshots (though it's not necessarily the number, but the
amount of diverging data that seems to be the trigger), sooner or
later the whole system slows down a lot. YMMV.

But even one snapshot is super helpful to recover from minor user
error. And on the rare occasion that I need some older data, I fish it
out of secondary storage with qvm-backup-restore.

> How do you do your backups?

Nothing fancy, just full qvm-backup runs every couple of... decades.

Rusty
-BEGIN PGP SIGNATURE-

iQJ8BAEBCgBmBQJbr2zxXxSAAC4AKGlzc3Vlci1mcHJAbm90YXRpb25zLm9w
ZW5wZ3AuZmlmdGhob3JzZW1hbi5uZXQ4NEI1OUJDRkM2MkIxMjlGRTFCMDZEMDQ0
NjlENzhGNDdBQUYyQURGAAoJEEadePR6ryrf/eMQAIzEoB0KqLQCqpm+iHzrA9tm
k3yckoXPDfMxXUupfXQ7nNZNjOUXHG88Dftd66DZFszMtFIC6Hg58HjcvbgYe23k
NtoJTZOfLwMt6s74U9ZboHK0r8xGCX2x42qCFY2GYep0+V2aWytNHxJfoYgLRXzN
3FplocBnIb5IrNL6jRV0/HotZYakdzLz9JpVthnNkKLuibZ3StXQAZ9gzsVccyYi
gf/yfePf0d6DBlxwE50Sha5+NkXW3/pnKyZsS7NlTp44G2iCbiMgegYiksG11TMn
SzVDuIf3oWUgjxDwD+wtHYAnASaXCAg/tCKVNvlLz0Zk1URMJ/xdwRbC8UzNodLY
SAjUENOzRGLfOCF4r2xW7pU4RXHq55rr4TitZmvvzqFnBcNlcwXpY3I6IOoyGQGa
ud7f9LcREjQBopnUwiwUnFT35l5fu3Ypux7NO1O17FT63eBoryJrgx6l3w5mam4Z
ozYdd5ua02X/a1rI+KY+kdKBCBKgDO8W6/u/yKUxxzfkOsRLjonMXV1k5ZinxRfd
QPSyMkbmQZpV2Mb4hZn7Ui07SGC3K+TrB3sa0+tkGwdi18n27UBNLyXFqSma+ZhZ
rMLBwLQVA9I54S5xjjGQCHxeJQJP/yhXINsij5GdrlY56BX73Yf0dwke7pBIKHDp
8nHiLsEd0Skb0PjJNupB
=uEnf
-END PGP SIGNATURE-

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

Re: [qubes-devel] Build ISO from official uploaded packages?

[Rusty Bird]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

Marcus Linsner:
> On Tuesday, September 25, 2018 at 3:13:19 PM UTC+2, Rusty Bird wrote:
> > Rusty Bird:
> > > Marcus Linsner:

> In other words, `systemd-journald` causes a write as `Total DISK
> WRITE`, but not a sync/flush to disk, so not `Actual DISK WRITE:` ,
> then at at most 5-10 sec later `[jbd2/dm-4-8]` is the one that
> causes the sync/flush aka `Actual DISK WRITE:` !

5 seconds is the ext4 default commit interval (see commit= mount
option in the ext4 manpage), so that looks normal to me. OTOH I see
similar timings on btrfs, which supposedly has a 30 second default.
Strange.

> > > > Maybe's something else I've changed, however I do remember seeing
> > > > the HDD led blink every second after a new Qubes 4.0 install just
> > > > after setting Sensors to refresh every 1 second.
> > > 
> > > That's probably just your LED visualizing that the Sensors hard disk
> > > temperature command communicates with the disk (even though it's not a
> > > substantial write). You can test this by running 'hddtemp' in a root
> > > shell.
> Great idea! Thanks!
> From idle state (see the above iotop idle state), the following is
> the only thing that changes for only one refresh(5 sec):
> Total DISK READ :   0.00 B/s | Total DISK WRITE :   0.00 B/s
> Actual DISK READ:   0.00 B/s | Actual DISK WRITE:   0.00 B/s

The thing is, if your LED is working like mine, it's still going to
blink every time you run 'hddtemp', even though no data is written to
disk. Just a false positive.

> I haven't yet tried installing an .iso because I need to get an
> empty disk, probably next week, then I'll be back here with
> report(s) :D and re-read Marek's post/apply it...

Sure, no rush.

Rusty
-BEGIN PGP SIGNATURE-

iQJ8BAEBCgBmBQJbrRAAXxSAAC4AKGlzc3Vlci1mcHJAbm90YXRpb25zLm9w
ZW5wZ3AuZmlmdGhob3JzZW1hbi5uZXQ4NEI1OUJDRkM2MkIxMjlGRTFCMDZEMDQ0
NjlENzhGNDdBQUYyQURGAAoJEEadePR6ryrfmcsP/0dvfHQWQcRidOlkU9NVpHdg
wsC77rZaMLR/ljm/8sSbfGugTLTznSth18++8f6YtctCv05K9QNb5e3KD2SuIw4j
Viq2iVuYuqUBSHAFEQYWf2OZJeLjBQxCkwO76KKGQcw0AwXCRCWyTlXetPykZYbL
TXuValFPvgdkb59B0IFZpnMw/jZwUmQJx/UZGm5kUyO8H3yWNiIQp3ipwceuKhvf
9L7Pg/+fZ+5j28oLpVwH9gyBvklvPqqJWfzPjnkPQKRN13/SGV9T92zwTE3n5Fl3
XHtZXNNa+vPcaEfViqA511PadD8fwHmHQIuCvr6bySDEhpAdF6lHxmhKB14c/WAO
J/JAwVYzVyGw/ct3buCucKo1436mpzbeUN+ErCKiOOkEpeANQCOqWIMgpQwyRpRb
H0pIhJ4h+N7f+0Y4wi1MGeWeOots+4IoGTdc4DylKdHIaFrBn/AXtwc4pZyXvyFy
IPqOwH+Th1yB5fHUgQHHkQrVsp2iUToND1cajdeCGZ4h9j2gcRK+DoXfnafD73HM
gtnW6sUr3wNCTVGXfOEZk218wxRkx/IbQnHedEnp7CdTUbA7A5WhtDKSG3IYlmDH
iNI4fu+m7Wi0irdnPQE4gFQUOeVpnFjJkJjfw38QUQYJg8wYQs67FtKG8woyuoPA
ibtKw9RbLnFLc9qZlhA/
=lCQE
-END PGP SIGNATURE-

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

Re: [qubes-devel] Build ISO from official uploaded packages?

[Rusty Bird]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

Rusty Bird:
> Marcus Linsner:
> > 2. in another terminal: sudo iotop
> > 3. in a 3rd terminal: logger
> >
> > every time you press Enter in [3.] [...] "Actual DISK WRITE" is like
> > 15KB)
> 
> I can't reproduce this in my dom0, which has vanilla journald.conf/
> sysctl values and kernel/Xen parameters. "Actual DISK WRITE" remains
> at zero when I log a line.
> 
> > In /etc/systemd/journald.conf I've the uncommented
> > "#SyncIntervalSec=5m" which means it's at its default value.
> > 
> > I'm not sure what level is 5 [...]
> 
> "5m" = 5 minutes, i.e. EMERG/ALERT/CRIT level messages are synced to
> disk immediately and other messages once every 300 seconds.

Oops, sorry - I thought you had mixed up the log interval and the log
priority, but now I see you were referring to the dmesg lines prefixed
with <5> in your post. Those would be level NOTICE, so they should not
cause an immediate sync.

> > Maybe's something else I've changed, however I do remember seeing
> > the HDD led blink every second after a new Qubes 4.0 install just
> > after setting Sensors to refresh every 1 second.
> 
> That's probably just your LED visualizing that the Sensors hard disk
> temperature command communicates with the disk (even though it's not a
> substantial write). You can test this by running 'hddtemp' in a root
> shell.

Rusty
-BEGIN PGP SIGNATURE-

iQJ8BAEBCgBmBQJbqjRmXxSAAC4AKGlzc3Vlci1mcHJAbm90YXRpb25zLm9w
ZW5wZ3AuZmlmdGhob3JzZW1hbi5uZXQ4NEI1OUJDRkM2MkIxMjlGRTFCMDZEMDQ0
NjlENzhGNDdBQUYyQURGAAoJEEadePR6ryrforUP/3DChOxeOfZFjKqyf+OuW8rF
cMX/yjFzufap7vjX0yikndre9h4Zdynw/5CM1T0t4qUDG1sdbKxxxJo8W0i/+cVm
hfFWf+0XiW9tryOkx6m7Rd544YHfE5c895T46RFKKbkr4Fzr0iadkEknv1soS8N9
MNGL4yufiX9z24s+da8MBdprmN5bdrGmiIxGKKAvVmP18JmD02QrUiXdVem/unsk
so/F2hgEjsNHpjMMetZO2qu53Q7y5h5d7s7yvvzYJ338VrkfqWWjxDQDFXWzymWY
1nvX4SpUM0bWPzpfVW/rjsBxcVxH9wSPzmDMagXvG5IdA8vGvmZlygImlWcssish
jbQ3h5LURxRQh7zwY8L3dia00Ur4L86j+QXAtaGU9+476+ggBXbKgDIcChjXOhjJ
K9DMGp6Q/qPHECYSEXoR+QqV+h60dS91Gsf/mG9i5klDEDobm8XJIz5USTifHwVL
YdR2G3B9t8AqXtdLOL3yfYpLOyzt3MP1SEq1NnJ6/cB1vqo02CNWS8+HwBPq/Lle
f2vHFK6dWDIuUIotIw5AZnEWi+VVJ/rrMwEMQDvjIqzgGxealu2y8RL3F3I4GRly
fC+M7ocjoC9ITiOA0La2xMViNN5pVroEWEiukANadwe6qq11lFC+pHR+Mw21Zsb1
lJrPFWNM0EEIYf8cJsXb
=5nia
-END PGP SIGNATURE-

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

Re: [qubes-devel] Build ISO from official uploaded packages?

[Rusty Bird]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

Marcus Linsner:
> 2. in another terminal: sudo iotop
> 3. in a 3rd terminal: logger
>
> every time you press Enter in [3.] [...] "Actual DISK WRITE" is like
> 15KB)

I can't reproduce this in my dom0, which has vanilla journald.conf/
sysctl values and kernel/Xen parameters. "Actual DISK WRITE" remains
at zero when I log a line.

> In /etc/systemd/journald.conf I've the uncommented
> "#SyncIntervalSec=5m" which means it's at its default value.
> 
> I'm not sure what level is 5 [...]

"5m" = 5 minutes, i.e. EMERG/ALERT/CRIT level messages are synced to
disk immediately and other messages once every 300 seconds.

> Maybe's something else I've changed, however I do remember seeing
> the HDD led blink every second after a new Qubes 4.0 install just
> after setting Sensors to refresh every 1 second.

That's probably just your LED visualizing that the Sensors hard disk
temperature command communicates with the disk (even though it's not a
substantial write). You can test this by running 'hddtemp' in a root
shell.

Rusty
-BEGIN PGP SIGNATURE-

iQJ8BAEBCgBmBQJbqWESXxSAAC4AKGlzc3Vlci1mcHJAbm90YXRpb25zLm9w
ZW5wZ3AuZmlmdGhob3JzZW1hbi5uZXQ4NEI1OUJDRkM2MkIxMjlGRTFCMDZEMDQ0
NjlENzhGNDdBQUYyQURGAAoJEEadePR6ryrfANMQAJm1KoJekqfR59jiN6T+TCKo
nYNYhNF0Ke5CPCrnAEOOOhP0HsZ9jRfIBWAIlgE3xLuoPYwC7Bv+nsPx8IWIe4uK
q567hzEZcHnMTRTHB9Z5mKw5e4y5HtmchgFRBzTUWWQFM+ir2vkE0wcsQA4FhIdN
4RhK/kaOGH1QxNYNNxQyu5vly5fdDKipS3Fc2LDytIjqR8vpvV3KgAQX4mQ1Dswc
E4FalCOqj/DKR7GnkhuDlAWAESD635rsety3/NG6S69HvnoXRPGRnY6L/6u0c1b3
aIdP+6wZv3IEziOZmb4xoqCCmdScqajVnnNOmw4zr/wmV2gXbNzArDD8SZ2k/dx1
OZ9LzAZLUbQt9npx1F3+oWLe/r+zCqWWvOZXSsW5au0jBbMbVTvrxppgbHrpIPLt
tPTi5IUBkI0jacIcTSh69VK1CyBIpiZ6FHd4Arg7/1dEL2LBwR0ZuFYkvAdfKRAy
PVzc7EVgeEgk9JTHvwZp/kqPuuIG+yNoSqlaFfpZPVeoBrbEgq3xK/0C/HvQahoz
HnVzVt4PFnM3jXMWAUANWFARixecNPMmegzMQINX2HzCYcjvmWm1bO/L0bXOIfx+
msg/gDj0a1R2de4EpZ6z5fO4QVqmPQvBysWsw0wqMi9D+/64DEIroIJczgQtJGOH
O+eHHDszWj452vikWbYl
=+gnj
-END PGP SIGNATURE-

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

Re: [qubes-devel] Build ISO from official uploaded packages?

[Rusty Bird]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

Marcus Linsner:
> Any chance you could post full steps? like from a newly created qube
> based on a fedora-28 template for example.

Sure, here you go:

$ gpg --fetch-keys https://keys.qubes-os.org/keys/qubes-developers-keys.asc
$ git clone https://github.com/QubesOS/qubes-builder.git
$ cd qubes-builder
$ git verify-commit HEAD || echo DANGER DANGER HIGH VOLTAGE
$ cp example-configs/qubes-os-r4.0.conf builder.conf
$ variables='DISTS_VM= USE_QUBES_REPO_VERSION=4.0 USE_QUBES_REPO_TESTING=1 
INSTALLER_KICKSTART=/tmp/qubes-installer/conf/travis-iso-full.ks'
$ make $variables COMPONENTS='installer-qubes-os builder-rpm' get-sources
$ make $variables COMPONENTS=intel-microcode get-sources qubes clean-rpms
$ sudo chroot chroot-fc25 dnf -y install dnf-yum
$ make $variables COMPONENTS= iso

If any step fails due to a download error, just rerun it. Unless I
made a mistake putting everything together (in which case, please say
so), it should spit out an installer image file in the iso/ directory.

> I'd be very interested into building(and testing) an iso with all of this:
> "Rusty Bird have done excellent work and contributed file-reflink storage
> driver[20], making use of copy-on-write feature of btrfs, instead of
> building device-mapper layer on plain files.
> - From now on (including Qubes OS 4.0.1) if you choose btrfs partitioning
> layout, by default file-reflink driver will be used. Existing
> storage pools are not affected by this change. " 
> ^ from: https://groups.google.com/d/msg/qubes-devel/MakHbJKbfwk/1PMvmjf3CQAJ
> 
> I wonder if that means what I think it means: no more lvm/thin pools
> and instead only btrfs? That'd be crazy good :D (tbh, I'm not even
> sure if it makes sense)

No, you're right. The only thing you have to do is choose the btrfs
layout in your shiny new installer:

- On the "Installation Destination" screen, select "I will configure
  partitioning." and press "Done".
- Enter and confirm your desired passphrase.
- Switch the drop-down menu from "LVM Thin Provisioning" to "Btrfs".
- Press "Click here to create them automatically." and "Done".
- Confirm your passphrase again for some reason.
- Accept the inscrutable "Summary of Changes".

This assumes that the destination hard drive is completely empty. If
not, try the "I would like to make additonal space available" option
on the "Installation Destination" screen.

Let me know if everything works. You'd probably be the second regular
user of the file-reflink driver in this particular universe.

Rusty
-BEGIN PGP SIGNATURE-

iQJ8BAEBCgBmBQJbprgDXxSAAC4AKGlzc3Vlci1mcHJAbm90YXRpb25zLm9w
ZW5wZ3AuZmlmdGhob3JzZW1hbi5uZXQ4NEI1OUJDRkM2MkIxMjlGRTFCMDZEMDQ0
NjlENzhGNDdBQUYyQURGAAoJEEadePR6ryrfGPoQAI8KG/sPJQSy2vvFi4p33Pxv
qQQ4uTKC6nQCdqFKBDJkv1AWvATVr6WxE4s2NyU10tfAJ3lS/v/xFtZ5wM6LyrT0
6N5aq932HDmBV4qwa18y2mOXxFuzrUEYJuEgObBhMQC1D6We/gIBgyRLYZ85ekpn
R0Zgst+haFyU5qI9KEEYrvLl+MzaNAJcGY3NyLetkKbqaW5e7eUhJTo59pN1HMHs
4MXAEMy6NInoDETK31UKavbMzRNA0kx6h9KPE8kLwEwhJtOiCJBFRmFDwvuAp3yL
GlTPct3MWFRB7g63VMXel2/YxFhUeZlWXd9M0bA7quBdJq79c/pDvwujZONHtw6Z
sbDDLpuataPevTn+j9+RkGTaDXdnpS+vd9oopiJEywbvk8bWvDP/MIESwVLedmMx
T17Qu+OjvUV+pkQre3KRTO7L2eDvUdfGp7Bm2iIwdiwK+ymbBFfBprXAGxv3ojHs
nXinNwAy1FJp/wfifB4IQ4E/UGZxOSVHSe+sgZjf8l/ctRhxGT7e8vnKsGML8W/0
ewHOYmfq/rRJChVi5cX7AhldAQlrZMzdlrxiAe57Dl8DrEj0R6h6Q3paLD5/ewiJ
GQ4rttSWoZlhl+6Gvrwgp0aTzQ4m19xAbxgdKM5/sljka2x7JcPoBlGE4ygP60yI
8DaX8A4yfu7q32IyCNOS
=VsyN
-END PGP SIGNATURE-

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

Re: [qubes-devel] Build ISO from official uploaded packages?

[Rusty Bird]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

Marek Marczykowski-Górecki:
> On Fri, Sep 21, 2018 at 11:48:17AM +0000, Rusty Bird wrote:
> > Now, if I run
> > 
> > $ make iso
> > 
> > it fails with:
> > 
> > -> Installing installer-qubes-os build dependencies in fc25 environment
> > chroot: failed to run command ‘yum’: No such file or directory
> > make: *** [Makefile:519: iso] Error 1

> It should use dnf... Anyway try this:
> 
> sudo chroot chroot-fc25 dnf install dnf-yum

That did the trick, thank you.

Rusty
-BEGIN PGP SIGNATURE-

iQJ8BAEBCgBmBQJbpVQsXxSAAC4AKGlzc3Vlci1mcHJAbm90YXRpb25zLm9w
ZW5wZ3AuZmlmdGhob3JzZW1hbi5uZXQ4NEI1OUJDRkM2MkIxMjlGRTFCMDZEMDQ0
NjlENzhGNDdBQUYyQURGAAoJEEadePR6ryrfjZEP/jPxy6nsSmC6Y8cJoOaWfwYl
xNtAensAbI+0um6pMPlmvJc1q5zDY9AgZGo8kWAzEUMA88CvJyC1xuW23zZtxlwu
13H2dyRALmxFda73s23IKhutxadARYTPv60GyJnXd9DUHM/ppXkiyMlZjcpq0jNo
pR3bqEQpM8D1L8AugjVmHmO7LkZQ892WoSswYJDVC0jvHIydaIYzNhkx83IpbQ8o
MnDHI6mlDzUm7C+UQCN7uX8DbrQZA+UpYJkzXBFVTGM/nhzVR7k44m1V6NbFMLI1
MaX+37EarkQCHGtCJZXGxlqGk9RZQMjmRxqUROW8mKvAOlDWvPXY0lHzspCblA4A
zJHfSmYlyRnK3GApeBtwrROA5btzf1oWiOci3TT2VFctEz1KjlV3lua/8/b13RX+
fqa49Fyr2f8uiJvmZEnaEz84SLjJwomclBRPblnW33HKAZM0v6V8LAyAgImESmut
g/TY4fGh8hVrSuOahvoXk61FGXYTrMeo7qKFGnVaUAbFKUfF9bbbATRSiDtO7QPx
/x8hVe4cST6EQ/3kp4LNmOY85czkJlTnPqJoSWbucvB5k2dRdiDCT8n5j2FsmjE7
xJfZYJEM3eItZXO/1Orme4sczb/TrlYji1U1MjbuhilN7TlNhubXZtlE92g5o1GM
uD2dZrjHVlXOD1yweUOY
=0WqO
-END PGP SIGNATURE-

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

Re: [qubes-devel] Build ISO from official uploaded packages?

[Rusty Bird]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

Marek Marczykowski-Górecki:
> On Fri, Sep 21, 2018 at 08:51:52AM +0000, Rusty Bird wrote:
> > Is there a way to build an up-to-date R4.0 installer ISO from the
> > latest pre-built official packages in current(-testing)?
> > 
> > I'd rather not rebuild all of them - just the few for which I have
> > extra patches.
> 
> Yes, and it's quite easy. In your builder.conf:
>  - clear COMPONENTS (for the build time at least)
>  - clear DISTS_VM (unless you want to use local template builds)
>  - set USE_QUBES_REPO_VERSION=4.0
>  - optionally set USE_QUBES_REPO_TESTING=1
>  - set INSTALLER_KICKSTART=/tmp/qubes-installer/conf/travis-iso-full.ks
>(file is in qubes-src/installer-qubes-os/conf/, but it's in that path 
> inside build chroot)
> 
> This will use current-testing repository. If you want "current", edit
> travis-iso-full.ks.
> 
> As for COMPONENTS - you still need to download at least
> installer-qubes-os and probably builder-rpm (but I'm not sure if still
> needed). For that, you need to include them in COMPONENTS for `make
> get-sources` call.

Thanks. I copied example-configs/qubes-os-r4.0.conf to builder.conf,
inserted

COMPONENTS =
DISTS_VM =
USE_QUBES_REPO_VERSION = 4.0
USE_QUBES_REPO_TESTING = 1
INSTALLER_KICKSTART = /tmp/qubes-installer/conf/travis-iso-full.ks

after the big COMPONENTS block, ran

$ make COMPONENTS=installer-qubes-os get-sources

and then

$ make COMPONENTS=builder-rpm get-sources
$ make COMPONENTS=intel-microcode get-sources qubes

because builder complained that I need to build at least one fc25
package to prepare the chroot. (Is there a way to do that without
building a package?) Now, if I run

$ make iso

it fails with:

-> Installing installer-qubes-os build dependencies in fc25 environment
chroot: failed to run command ‘yum’: No such file or directory
make: *** [Makefile:519: iso] Error 1

I tried

$ make COMPONENTS=linux-yum get-sources qubes

but it didn't help. Looks like I'm missing some step?

Rusty
-BEGIN PGP SIGNATURE-

iQJ8BAEBCgBmBQJbpNqBXxSAAC4AKGlzc3Vlci1mcHJAbm90YXRpb25zLm9w
ZW5wZ3AuZmlmdGhob3JzZW1hbi5uZXQ4NEI1OUJDRkM2MkIxMjlGRTFCMDZEMDQ0
NjlENzhGNDdBQUYyQURGAAoJEEadePR6ryrfJZ8P/A+g8eViQv7Gz39nzRDjYA6c
e9YpuAiRqYX1H1y+bjyfbFzH2qt4TjHxFToACbZrQ1k0fcOTa0Bj4Kb3r6w86LJI
Rh8+GkOlKq7XxJeootTAn16S434SzjZCKeeIvn5FjxLHSeIOw/pQ5WVk8qW37oDi
fh99LI6FEXLvWsckzCwJCNbuFmEPMiyvtf0fKcjVKnm0UERQ7QNBe1TzqWDG6Ii3
eRua30dm1G7x9tqDmzAMmbgE4DAaOe2wFCosFpcdwHqhb9w+Y2j0Al33ppDge+Dg
8Mk5bFO2xF/pH+OxAEjpf+Uz06ORll+tjXdKKUSKfDDtYS+VuhZgryZtz0/sRGip
NLINsJt6aOJ0VHKIEY2pBkUnaiinI5GMhPm8NxAuWQ5cznuMuq6GTj8DAFH7nqGo
gUc78pvDeZCgIvCPuILkBJS5HuquGU2Q4n7Ga8hyT3kwyJtzF009CuJe7WpGah/8
nCJFpvPZvsm1b5ouNdIqyDb++HB2nRTfCRS9CT5gRyBE2RP+fmYr3Hgv6myL1r2P
MZc2sBVfI36AfqBEv4acKZJ4eXeoTbXaPQ8iaNAtcC/NZoKzh74SLwwo3etjhasQ
nT6RYDDDHsCy2XDwMJtH2dRr8HUgz9eyMNIoYEzw4FwbPl9aXTlP9AFKzHHeibFd
RGdxATKGmpdV+mUZQBsR
=4nYj
-END PGP SIGNATURE-

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

[qubes-devel] Build ISO from official uploaded packages?

[Rusty Bird]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

Hi,

Is there a way to build an up-to-date R4.0 installer ISO from the
latest pre-built official packages in current(-testing)?

I'd rather not rebuild all of them - just the few for which I have
extra patches.

Rusty
-BEGIN PGP SIGNATURE-

iQJ8BAEBCgBmBQJbpLEoXxSAAC4AKGlzc3Vlci1mcHJAbm90YXRpb25zLm9w
ZW5wZ3AuZmlmdGhob3JzZW1hbi5uZXQ4NEI1OUJDRkM2MkIxMjlGRTFCMDZEMDQ0
NjlENzhGNDdBQUYyQURGAAoJEEadePR6ryrfhowP/0uNWXJdcKlSNi18AgJVTJTD
sRdcrbVbazJwXV8nclrD/Es68XYili4ie6oyfoxwn7sxB1DTN7CXXo3fk9C30M4Y
EoGPAt3KdZ8Aen58JXRF9XPRrShiihDi41gttkpCXuYKYQLLqXrrCxd8chrbz1Wg
K7zJv1vDfgzZzo7xFInTWfQJhfdjhF4NihB+55PXb0DQcJEbsddm8LCC4kCDtaNh
fvY85Ks9XB0xxRvnaT4DLNDDmug2cX2Vdpmq3E8vUwz1qVaodCjzhcW/ofh9s/AF
18ZBttZjLmrOvnk/EV0mNqJOKotWevmIXKVr1TDxBiJHu/7NwJrZP3LvVVmDgD8K
KBILj5BcaWcxmAyeIi5Pc7fxyv7FIc8FjWFiZTb5AqEgUg69sf7K4NAB+J60iKY5
xVAMPGUf2uA3AmqMNAriHD/UD4duOFJ5mu2VIza9vFmawzgyueb6yMLK7WZFNpbV
rxNMZ3rXExCW5vhvhQqAS9GQLMaKNkKbzA0kOMWowlA2K+rJfJ0ctpmQOT7ysx8R
4Cibvn7AZvcz3KyA0unYVYbkj/2Btm5s3SCISpizmItLiXcA0/MlLFAFY7oAoz1i
Ms7I9WA4ksIh2qZTNXeazss6TOnnQ7yp6Ve67ZClHt55NTPhNVfF458T1FC8fBOa
AHsxEDKOCBVOzZ7OkFoc
=63bt
-END PGP SIGNATURE-

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

Re: [qubes-devel] qid/dispid recycling vs. Tor circuit isolation

[Rusty Bird]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

Jean-Philippe Ouellet:
> On Wed, Jan 3, 2018 at 7:02 PM, Rusty Bird  wrote:
> > Hi!
> >
> > So, the qid/dispid of a removed VM can be recycled immediately. When
> > that happens inside a 10 minute window*, it could break inter-VM Tor
> > circuit isolation, which is based on the VMs' IP addresses.
> >
> > For dispids, a relevant collision happens with ~ n/1 probability
> > (where n is the number of recently removed DispVMs). For qids, which
> > are allocated "lowest first", it seems to me that it should be more
> > likely to happen in practise (depending on the balance of deleted and
> > created VMs). Consider something like the following, where two VMs
> > both connect via sys-whonix:
> >
> > qvm-kill   identity1
> > qvm-remove identity1
> > qvm-create identity2
> > qvm-start  identity2
> >
> > Better not rely on circuit isolation between those two identities...
> > (As a workaround, the user can create the new VM _before_ removing the
> > old VM, if they are aware of this issue.)
> >
> > Proposal:
> >
> > Let's keep two lists, recording qids/dispids freed since boot, similar
> > to DISPID_STATE_FILE in R3.2. VMCollection's __delitem__() would be
> > wrapped in a lock and add the qid/dispid to the lists.
> >
> > Then get_new_unused_qid/dispid() would acquire the lock and randomly
> > choose a new id from the applicable number range that is neither in
> > use, nor on the freed list. If this fails, it would expire some old
> > entries from the freed list, i.e. the oldest qid or a batch of the
> > oldest dispids, and retry.
> >
> > Does this look okay?
> >
> > Rusty
> >
> >
> > * Or whatever timeout is configured as tor's MaxCircuitDirtiness
> 
> +1
> 
> Did this go anywhere?

No (sad trombone). Part of why is that the case I care most about
(dispid collision) _feels_ unlikely enough (and for Tor Browser is
mitigated by its per-startup circuit isolation nonce) that it never
seemed urgent to pester the core folks for feedback. Especially since
it might take me a while to actually get around to implementation.
This assumes nobody else wants to do it, hint hint...

One possible simplification of the scheme would be to choose the qid
at random instead of lowest-first when creating any new VM; bump up
max_qid from 254 to e.g. 2^16-1 (which has been proposed for a long
time); and use the qid in the dispN name and the IP address, instead
of a separate dispid - so there'd be only one "recently freed"
blacklist to maintain.

Rusty
-BEGIN PGP SIGNATURE-

iQJ8BAEBCgBmBQJbg+f+XxSAAC4AKGlzc3Vlci1mcHJAbm90YXRpb25zLm9w
ZW5wZ3AuZmlmdGhob3JzZW1hbi5uZXQ4NEI1OUJDRkM2MkIxMjlGRTFCMDZEMDQ0
NjlENzhGNDdBQUYyQURGAAoJEEadePR6ryrfMWEP/3Ein1qUmXBOe30tTc/bRWiK
XAEzyLiU4dEU9hmk0m4zE0DJDhTxcvI/XS3DVN3dXj25iE7U+JQ2bZAfhfQbbXhi
wPsPH2L9sXxsZgl0P2nJRtXJslygQhHOh1jSglOlf4mVDGcKfz4UpKkddLDVRt4h
3HfbUd8mMtLA2h3TgEQrj29BDxpxvf1x3A1kwj1y/avZDqhZzNJsecpbCEnEnaas
/MGx4QrBC4q7rNZRCQRj+2XcYNK8BDCJxu/4TeBKqjLXZu+/uFxxodGfE49P5FJ6
3pvKZ/omBpiK+qzbP4vHqcqeFzRFsifdt8BnNZB1E3piQBsu3+/n1XyMgsCk28uS
L0/OyV0HKmqB7IX3gNIfiCum+o0EMCHbvYg6+dQucawIuxKoGh8y7bSl3swR872E
fLw7W4tsU7pXJ2yIW/iFudM818dXQnaMSjKhcdkGyH6SXjvPHNDEFKut5Bnz19Dw
YE2ixryqcXDBXNNMFpDEC8WJxMk1P9YT8fJkt5agY74kNqUFtaZ0FEkVP06h2GTC
vDkWm9dllvo7xtl+AhNclBuq0WiquIY8afgpiQfgjzbWm8UtuFhFQ/HIMUwR3F1v
gqpgHEmFEgGSurgnKkQbC7DxVdh2Jh6hR14D4IQzmalrzVaMtqB1YKACSXaxa64j
VDrbm2ty6mkLVuiWPFSX
=aLzW
-END PGP SIGNATURE-

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

Re: [qubes-devel] What happened to last year's GSOC submissions?

[Rusty Bird]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

Elias Mårtenson:
> Last year, there was a lot of activity surrounding two really
> interesting projects: One about improving the AEM feature, and
> another which was about being able to mark downloaded files as
> insecure so that they can be opened in a DVM.
> 
> When reading the posts about it, it seemed to me that these projects
> were pretty much completed. When can we hope to see them in Qubes 4?

I assume that Marek has simply been even more busy than usual, left
with no time for code review of peripheral components. Fingers crossed
that things will quiet down a bit once R4.0 final is released (and
some new bugs shaken out by the wider user base are dealt with).

Rusty
-BEGIN PGP SIGNATURE-

iQJ8BAEBCgBmBQJaeMUMXxSAAC4AKGlzc3Vlci1mcHJAbm90YXRpb25zLm9w
ZW5wZ3AuZmlmdGhob3JzZW1hbi5uZXQ4NEI1OUJDRkM2MkIxMjlGRTFCMDZEMDQ0
NjlENzhGNDdBQUYyQURGAAoJEEadePR6ryrfeIgP/3bgWUjMgVK6oHj0rwMiZlA0
gAx2w78NokjdJTs2zF1TDCNMj7+VpXMrYGHn0hCxcsfYdZRkjPonhfNrbAO6SYOB
p08H9z7MuICUVhBxkSigy6FVNcBK73Re9nHhWUzQ8ANJL1RmHBpCJIH8FzKG6xtK
d83iilYtOAZl2gooS1BPwW9O/dB5k3KxRYpzPhBpl60RsxMaGqI5GP4gC3RThUES
adoT4KC6aTCondtp8HZ6pWHptZ7zyGRPDWeOgSgSF9N9SLF1FnLyXeCQKr29Czx0
0IJxTB3fl104hYVLlf5O4iu2HSEoqNZPIxzuxfyoeBP8eIiIO7nzJKOhWsACXxnu
F8KPZFaSjzABUQyhcdK+6EUa1NIK8fWnptLS9js1fu5L3wdjC4xcRsdrNGuKAtOi
9nBEiEBbxbgRvDxBVPcAzEj5+bpOhqC/jFb/AdaUUOy940YXbjrZ5TG6fOpbwRGR
huhMonqwjEzsTBMnxJI39tPKCrcdU69wDKIO4MnnhLgSgmk5QfvoRXqI6ppR/BhB
vqVJxWQSpysUZaJ7DUad2+M7ue4C3xFPqfsBMreKQ9nPSS469wLMiveZEFNgQtZC
SZfwmB1mbZiuCy9TC7c/G9wSXpwgP+uiaTB8SLRFYQiMhp94cMkVS2GYMz1kNDuE
Il4ALB3j0oUnis+PO2rm
=s0A8
-END PGP SIGNATURE-

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

Re: [qubes-devel] R4.0-rc4 installation image considerations

[Rusty Bird]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

Marek Marczykowski-Górecki:
> Right now I see two options:
>  - abandon the goal of fitting the image on DVD (I'd go for this)

*single-layer DVD. Still lots of space on dual-layer DVDs, so this
option seems totally fine to me.

FWIW, I sometimes write DVD images to a microSD card, set the
temporary write protection bit using sdtool*, and put it in a USB
adapter that exposes a Mass Storage Device (but not MMC) interface to
the host - which would then at least have to exploit the adapter's
controller to overwrite any data.

Rusty


* https://github.com/BertoldVdb/sdtool
-BEGIN PGP SIGNATURE-

iQJ8BAEBCgBmBQJaYlG0XxSAAC4AKGlzc3Vlci1mcHJAbm90YXRpb25zLm9w
ZW5wZ3AuZmlmdGhob3JzZW1hbi5uZXQ4NEI1OUJDRkM2MkIxMjlGRTFCMDZEMDQ0
NjlENzhGNDdBQUYyQURGAAoJEEadePR6ryrfENcP+wTttj8plXbDDjhpcY+3q4l4
pXwPWZ7+iVjHgi56mwDAxibXYIkkEXbgkbd5Y7/E9xf1Zel4xV1FH76HN4gVqHJg
txDEB0SdURUNjOwNfc7jkc+0SQYAoNdLrBVN1t0QOMG0DA5SpQl49wmhP0CuKrtR
N/E6zEKdJPo0RB4LIHXBZAvTl607BV0frsAnY1RsFwuiKx8JNRRrWK/MWGzLt3WI
shQXKeEqz/FF/LIyDROjoElPUwUKWdyWVlKIysW5lmTJM1bgHrTGkYh0kO3rJsob
ecRjnTTO1nllqsxHAa3nkGk00LD7HtmqV7MTcU6yWNCksHvfSOFyHnjicRqXd5U0
ON188ZHvKIh9cN2zB03KROTMit8SOiuRVb8iZLfpylwBpsywz+jLaeGqY07icVsR
2XWw0qG3eWukmrPlav63lmDrIzrJYx4v2uIPGE31Ujdz0T4ADu4XvmZuv4ppF/Nc
98Dtx70NFFF4//bbQ7FJksvGqCj1bdWRF1WAHAQNDPEMtkAONLje2tXHosbgWDYR
S5q3SZ1NOEXx/2ofOFlJzslw36FfCEpmOcb2W3zIvTVUbN/xSjgc6huvZblHcqIR
2cA3wGDCls7iWHaC6nFymPDGw2Yu40bETHXiC2HPxtTJXb+iiZaS3yV1+PYsFAJi
5Vu2RhCx7K//fO8wrcA9
=WJYF
-END PGP SIGNATURE-

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

[qubes-devel] qid/dispid recycling vs. Tor circuit isolation

[Rusty Bird]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

Hi!

So, the qid/dispid of a removed VM can be recycled immediately. When
that happens inside a 10 minute window*, it could break inter-VM Tor
circuit isolation, which is based on the VMs' IP addresses.

For dispids, a relevant collision happens with ~ n/1 probability
(where n is the number of recently removed DispVMs). For qids, which
are allocated "lowest first", it seems to me that it should be more
likely to happen in practise (depending on the balance of deleted and
created VMs). Consider something like the following, where two VMs
both connect via sys-whonix:

qvm-kill   identity1
qvm-remove identity1
qvm-create identity2
qvm-start  identity2

Better not rely on circuit isolation between those two identities...
(As a workaround, the user can create the new VM _before_ removing the
old VM, if they are aware of this issue.)

Proposal:

Let's keep two lists, recording qids/dispids freed since boot, similar
to DISPID_STATE_FILE in R3.2. VMCollection's __delitem__() would be
wrapped in a lock and add the qid/dispid to the lists.

Then get_new_unused_qid/dispid() would acquire the lock and randomly
choose a new id from the applicable number range that is neither in
use, nor on the freed list. If this fails, it would expire some old
entries from the freed list, i.e. the oldest qid or a batch of the
oldest dispids, and retry.

Does this look okay?

Rusty


* Or whatever timeout is configured as tor's MaxCircuitDirtiness
-BEGIN PGP SIGNATURE-

iQJ8BAEBCgBmBQJaTW8jXxSAAC4AKGlzc3Vlci1mcHJAbm90YXRpb25zLm9w
ZW5wZ3AuZmlmdGhob3JzZW1hbi5uZXQ4NEI1OUJDRkM2MkIxMjlGRTFCMDZEMDQ0
NjlENzhGNDdBQUYyQURGAAoJEEadePR6ryrf9KsQAILsq77RF6ku7SFxwoTcAOJU
4W7kqNV37Bisig8aI0l6V54fS0yA5gbSzTwm5vjGaeTV/wrCsv2k0FJRrI53rWoM
6pQaLjv2l8LO2GrVwvPrAwWAoSnSjIs+rl8LhTcbBy0bL/mx/vJrxZkwdtsdhhqC
5o5hslV5Pw1+m6bbULT+R13muQ1/DAA71ukyX8qCbwDZA+u7Po+EexuwkDar4bAC
izK6L8Rr8W6/ZHPskJJgy9LcxpmBm+70n79foi5CYwjmPNTyJxGEV97qMpgcyzss
SQ6DDkS1RHF4Pp0IwTs46AqeoHEEGFajHu3twmLwwEJFEILbsm3dcxhGmtzUFmYt
VmgpfoiruOMcFs2j+qvr3A+IfsaNi7v32JVnIqCYX8XnaqrAPqjgrvFYQ/EUu8oJ
8+gKdzJlHb/LhYqpMcBON98x8FLWpIgOhUaQFmOtoTxmIyYZXDEGcb3BJsHW6xy7
BHEXLU+MQCNBVkfX/XSeCZsH9f2x+CvQBQ7T/86HQk8EVuCs5LGLHFuecOzKKi4V
BiPhN+sqDXrJcf7ZH8VugoahZN8dBe/rTyUwLavdTfxTGwJqv7VlmbdwlCMTKCq8
f5Z7LRD7neldkdmkOXho5eMQEQ8sfayFfMXMPcTsReccZznDgFZ0jeKfOv/v6WAG
2w2I7udGNbWqPfc1ZnIH
=/1Vt
-END PGP SIGNATURE-

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

Re: [qubes-devel] Remove SWAP file on SSD systems / provide option in installer

[Rusty Bird]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

Chris Laprise:
> On 09/26/2017 11:14 AM, Peter Todd wrote:
> > Re: privacy, you can setup swap files to use encrypted storage with 
> > *volatile*
> > encryption keys that are generated at boot, and never get written to 
> > persistent
> > storage. Dunno if Qubes does this already, but I've set this up myself on
> > Debian boxes before.

That would be https://github.com/QubesOS/qubes-issues/issues/977 - now
titled "Use random encryption key for swap partition".

> So now I'm looking at my /etc/crypttab wondering if I can change it to use
> /dev/urandom ?

For R3.2 btrfs setups, see 
https://gist.github.com/rustybird/917ac2560fe4e9541d1f
but it won't work on LVM, i.e. R4.0... :(

Rusty
-BEGIN PGP SIGNATURE-

iQJ8BAEBCgBmBQJZ7K9aXxSAAC4AKGlzc3Vlci1mcHJAbm90YXRpb25zLm9w
ZW5wZ3AuZmlmdGhob3JzZW1hbi5uZXQ4NEI1OUJDRkM2MkIxMjlGRTFCMDZEMDQ0
NjlENzhGNDdBQUYyQURGAAoJEEadePR6ryrfhBoP/iC4c8L7X5yOa5G9K32qfT/g
K3JPfFy7GadzZjXH9Qb4AG1ioP+IdwpzGgsJKSRCIO3DMXc63Q1cgftvQInEUaB+
CiLC/FnTaJEXWJUGnwJQmyUbh3185hRgfH9m3gtLkseYVaV5BA1EikNgEP4wmgce
EFhwCKhaKK0p7Be77QBwu64cHz15aLuL+vy0hCyRvnYZGe0Pl6mUj1ycWFym8TaP
B/DqAxVhkuuhhalP572r6tZWOH+hVAWXgXf+ZYYeYY7CTs+Bj46OKhqMe4nH6mnd
oLZ9K7qTt9W4jmBkbeLd7wutrJMYXx/mQ0Rzoqeth+B7HGnLZsAwnhapp3Rrdsal
Pu5QneF844TCZLq384rShvigMoigyMKJoKOCDFRmnhR74RWD7YFIgel7tnQd3AsC
m7yAjpjd9viRDYmzQKBeKDjax51kOBSfJzN8z0zzM81vcyaV0HLJNAcM4rHgzJF9
V2g0agDCQ2Dt/3Nw4Ns8mEH5eUEyiPS2+UywMvLYVWXbSZ2kiq5AO66yGRxsmewx
ciXNsE+Ui4c5j+GtdTHSC58nrIANKC1joCq56COPvf4cChSrc+e8OaG06DecJl9d
d04KimpF3GBNF/UV6rpHO6Go5gDSuWM8CXyZ+Q7pTlZZL3Ek5UZPFTAX+zEcUdLk
cd0OWjVuhxMAkoXEH2Zj
=ur/t
-END PGP SIGNATURE-

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

Re: [qubes-devel] [GSoC] Progress report: Anti Evil Maid enhancements

[Rusty Bird]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

Hi Patrik,

> I've opened a pull request [1] to the AEM repository.
> 
> Again, enormous thank you to Rusty Bird for being a wonderful GSoC
> mentor and helping me clean up the patches for submission.

Thank you for not going crazy from my nitpicking!

I encourage all AEM enthusiasts to review the code, and/or build the
packages and test them (on Qubes R4.0rc1 or later). And of course post
any feedback, either here or on GitHub, even if it's just "it works".

Rusty
-BEGIN PGP SIGNATURE-

iQJ8BAEBCgBmBQJZnD76XxSAAC4AKGlzc3Vlci1mcHJAbm90YXRpb25zLm9w
ZW5wZ3AuZmlmdGhob3JzZW1hbi5uZXQ4NEI1OUJDRkM2MkIxMjlGRTFCMDZEMDQ0
NjlENzhGNDdBQUYyQURGAAoJEEadePR6ryrfn1UP/3F/L5leJMGIUxTa9U7EpQDm
2MOCP0rF5Mrfacq5a/mC1ZC8bInFNTpO85MACSq6pp7TSPZCGsCWLymx05dguuIL
UceeW70dZQI350T/wdYuUxtZLQNUfdIgzSm9kRJFEbe7Tt3WM/aSZTWas2WIoEAP
1pm/g41+vWZ5iPQXahcrpX45Of7ldqD4W+pS4/wlnw9mdqFWQfbDPZFWf4QRaMTu
f/FhoyE7yH0Z25J7CBlpwbz740r8M1+VYrkh0sEA3Wvp1gev5/BCYlgxatVal+kG
ikLzNuMPIcnPbTc6zuyQ/Kr3FmprHPHg6Q2Le/YyQqVwiSrv0OAFGjD9Bw9gtaoJ
6sUfdY0hhBZTX6eTCgyU2fdizgJ9xR0TB+nBjp3PASoo7EzLq1LpgcpXqXbnvREg
msKGf5Ex23yw69qHUTHu0EC9Nxu622M4RnSNYv93bJouY7pjSTIcr/q5SfyNmCrY
rUtCIL008GFzyHNcnlRv4v/KlZC5E1vgfX03dEnWl4UyA1hLsoXcUX+U8f2VkWLJ
DXbOxZfi8v5VMUd2AHRJM7s6yd0wuvTpARPmTb+GqzGpKSett6keQdoA8kN7MpO3
OUD9wn5LoM4oLg2rjP2HZSQVBOpY8DW1t4MgSgf06VUnFv5fC/n5n8Hc4wMO5JHX
Cc3rVHxjIxlzIQR5oQT2
=fcPT
-END PGP SIGNATURE-

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

Re: [qubes-devel] [GSoC] Progress report: Anti Evil Maid enhancements

[Rusty Bird]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

Patrik Hagara:
> I've updated the README a bit [1] to (hopefully) make some things
> clearer. Also added a section on how to recover from compromises.
> 
> Rusty: do you think it's ready to be built and pushed into R4 testing
> repos?

Almost ready IMO. I have some more line comments, can you open a PR on
my qubes-antievilmaid fork? (Just so that I'm able to insert comments
into a flattened view of all commits.)

Rusty
-BEGIN PGP SIGNATURE-

iQJ8BAEBCgBmBQJZlGn/XxSAAC4AKGlzc3Vlci1mcHJAbm90YXRpb25zLm9w
ZW5wZ3AuZmlmdGhob3JzZW1hbi5uZXQ4NEI1OUJDRkM2MkIxMjlGRTFCMDZEMDQ0
NjlENzhGNDdBQUYyQURGAAoJEEadePR6ryrf7HAP/AwBCZ8ulOeKusfyxi2euc8w
8XThhrzzPpmzXqi73v8HOrXxrn99Yq+4JQ5w7AVSNFwmkTMkeSTgPk/qPseo1JCX
eaVMPwfzRTU6cWviZrsNpIth/5A73hke4eux3UivQqQkJjEzzNggxL4d2j3V/gL4
XcJJ/TS/DA1m3YsyyNdd4iDIujMQoZmikkt+JxHorhPoAWBEZd1CaBPrHgZwWLAa
lAf3PIihZtzrigd/aG6m03lhuhdUhfKxJU3vIIlnYVLD0D2LjNDHOvXMjmxsKTn+
sIaMsKYS7tWDlfazHavAo8xZFylh5fYQFhLWkaJwNAzHEenb8YF56A/R30uM5cNH
E2tIvBewdyepkDNf/ajVAy1Qs9Fm3fMyOKBMurY/X6H3vCCUOyXJn0lmD6N/cCJK
d0caNybEFU3V1QscIxUKAjodmqkeb16hJ1aQeEuBksN88dGQOmCKes0Ugv8HNAd/
hf28Ym4lQSwcI3mzlXpW02Lr1oY+NjWOUrDiJJmr3W3Kr73BiTH4U5iP6WYaWFB+
Ur9+Td9hUvw4MT8nOy3S+R9iLfC0POP/O3vfEe8U//PqJBvd5qrXkpdrg/dCxaq5
Iu2IbzwJrFke5e6563u8pcMxTAGg0ZNzUMPYLGAt3lIodBv3VYl4Gd5PaRcvHjo4
bzuKt1THhtNrnj2mtK7/
=XIQ/
-END PGP SIGNATURE-

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

Re: [qubes-devel] Qubes Security Bulletin #32: Xen hypervisor and Linux kernel vulnerabilities (XSA-226 through XSA-230)

[Rusty Bird]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

Marek Marczykowski-Górecki:
> On Tue, Aug 15, 2017 at 01:59:59PM +, Holger Levsen wrote:
> > So, "sudo qubes-dom0-update" for the first paragraph, and 
> > "sudo qubes-dom0-update --enablerepo=qubes-dom0-current-testing" for the 
> > 2nd…
> > (IIRC!)
> 
> Actually:
> sudo qubes-dom0-update --enablerepo=qubes-dom0-security-testing

Looks like they ended up in the wrong place:

- - r3.2 Xen packages: current-testing
- - r3.2 kernel packages: security-testing
- - r4.0 packages: not built yet?

Rusty
-BEGIN PGP SIGNATURE-

iQJ8BAEBCgBmBQJZkwieXxSAAC4AKGlzc3Vlci1mcHJAbm90YXRpb25zLm9w
ZW5wZ3AuZmlmdGhob3JzZW1hbi5uZXQ4NEI1OUJDRkM2MkIxMjlGRTFCMDZEMDQ0
NjlENzhGNDdBQUYyQURGAAoJEEadePR6ryrfk3QP/2eKJPrh03TcfQjtlTnm7lVk
ZxNKOfhO0rwuWZ/oE5GXjKhhfbBY/LfrmGZl8X3Cm2elyiqh2vP7l6x2CevR7qRo
v8WBBYh3ALImosDVI1Eo3XB/asrmxSo/q3espnp8UmLFaus9ZChV+2E16cQcuWOu
m25r1wWTr4PiH7AFsBEibW37orgPPEhrP+umUj+QYjfvyPXFXw/MUvbsdoGTcwSi
jUyqC552F/zSz1om5M7QpvzLXQ5dxqE0/T8zwv0On4n5tzdVX0QFpt7n0ylWj8vY
9/5vQY9/7luHh4MJnMTB4FpBvilSSMBPhRcN9YpZPolEPBtHpQ41Cj9p0TscgNP0
Wd2lGKFYaEtpPzN4XUmKRxNKku8nZDFezLvzJe4VXxsUZCw4OM+932YFFZkBwant
cf6oVd6z1pPnf1lfpnBsA5lZkHp7VURhQrRZ1yEwJ1o8ZGODptLgq5LGVxpMPDeL
5UulQFE9TZtmyBcuI9v2ArT3mS07coFFJyNToMDsHTZ0GspwthLd75SZ/A7CKGuy
6Cfa86wtizjGyDqjOpDhhSDOciFwrtxWzAh1pnSPD1U3d/ac3W17Bvi029y45Euh
uwzJoQ240FUcVw11PuifrRJzrpsYTKZAvzTCBqr5vqZ9JRvsfGc2gn2RKPCR0alt
OQ6Rtz6AtcVQ1pkFEdM8
=hFi/
-END PGP SIGNATURE-

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

Re: [qubes-devel] [GSoC] Progress report: Anti Evil Maid enhancements

[Rusty Bird]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

Patrik Hagara:
> Finally managed to track down why unlocking disk with unsealed and
> decrypted LUKS key file didn't work on a clean Qubes OS installation.
> 
> While starting to develop this feature, I added the key file path to
> my /etc/crypttab and had forgotten about it. Fresh Qubes of course
> didn't have this change. Combined with one weird systemd
> incompatibility (the B point in this [1] forum post), it had caused
> the key file to get completely ignored.
> 
> There are two ways to work around this issue [2], neither of which is
> perfect [3]. Both solutions' downsides are pretty insignificant and
> most likely not applicable to 99.99% of existing Qubes OS installations.
> 
> For now, I've decided to go with the second option (ignoring crypttab
> even for hostonly dracut setups).

So, to summarize, rd.luks.key works in both hostonly and non-hostonly
mode now, with this change? And rd.luks.options=discard (instead of
rd.luks.allow-discards) does too? If so, that seems very reasonable. 

Rusty
-BEGIN PGP SIGNATURE-

iQJ8BAEBCgBmBQJZkIxHXxSAAC4AKGlzc3Vlci1mcHJAbm90YXRpb25zLm9w
ZW5wZ3AuZmlmdGhob3JzZW1hbi5uZXQ4NEI1OUJDRkM2MkIxMjlGRTFCMDZEMDQ0
NjlENzhGNDdBQUYyQURGAAoJEEadePR6ryrf5RwP/2iVQGV6k44eq6JbpNJjoSMb
ViyTqTyJExL66GtDHQ684p36gD8/Pt+MXLLPHWm73sowQm1Sp1A74yr7m04WkW+q
9udraH6f3BWN8j+Jue0pxsPg5iONa/DF81+BDLRz8AitRftoUH9HClDJO0hxhNTd
nPgOlLSflZzfQFi5x31r8boXx1bSe9FxTXRy79sRb2WIAZMrkmTbwdk8c8Efe4Nb
nZYgd78V3f9Oo/xFfZtrYgo1fVC6r2sGSSFTYDizTwVUPu+cBXfND2NL/EwT9Hc5
gP2xy1FRClbA0OByDlHIf9Bm1NIaf11/IoUEuhXRyqhB5NUWpS3fSte2kjdbwDuf
kg/llsqChHa6X320NUsnJal/kd/939dmjsVHMXYp8ErJmk1iaF5ZflyRD9bvoKza
wqdY1DpQBfT4n8yZzbQ5kjqqH66GjlrsmjKDBGEf9gmH1jqJVMNs2uadkrtn8gf3
qd50nckperlBpAfHUKtndktnuNm1MgHnO6g8Icv1PNF/McWNEWDAIT32LVALOnfc
VQEMG1YLXTE/4bvpInUM7Gk2qkmwsv5Gt6E4j6ol7XGSQ84x5HpnZSQYLcWW5WCH
TDpzl6SgUxbxtVVJ23RGZ/kCnEcufd/+NaFAy4SzXnICkwEQOtidoKzJ2fjhFPRl
W+dnH3+KbAA3QbBXEu/1
=Fjbf
-END PGP SIGNATURE-

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

Re: [qubes-devel] [GSoC] Progress report: Anti Evil Maid enhancements

[Rusty Bird]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

Patrik Hagara:
> Would it be OK if I squashed all the commits so far into a single
> large one (as there's already quite a lot of reverts and design
> changes anyway).

Yes, please do.

Rusty
-BEGIN PGP SIGNATURE-

iQJ8BAEBCgBmBQJZd5J7XxSAAC4AKGlzc3Vlci1mcHJAbm90YXRpb25zLm9w
ZW5wZ3AuZmlmdGhob3JzZW1hbi5uZXQ4NEI1OUJDRkM2MkIxMjlGRTFCMDZEMDQ0
NjlENzhGNDdBQUYyQURGAAoJEEadePR6ryrfLTkP/RwyStNxTX3jGZiCIu3PjygX
rf4NQaBrMJO3kkPGd/iAylMEIxqC+aagiAk+VqfoM4GdVudQNfqD+oXO28ARZbBO
ds033AbccgK534fWsda2xrv1aprkfukshLffj4tmugs2CnqeQevkrpwKuAgs+aLr
n0odyTab3E448IhR9hC8u7MA725fujq1eKblB/unKRCIuQyAwZF0NPyPKCUTgWvg
SZxKpQV3AawPBnxTa/Jf5K/DD+jCJRS4qPa8qgaPyqOV+aP29ujjisVMFK0Pjfpr
sWU2tPkknuQ0ZILvU6cJHBHxy5QjBEjrgD3iQNpNAbkbNqXj6BPI8auPpi3WA4ZG
N69Ey6VLWjS2feEu2ej/EI1+4x9KhHg5yHiXGlIVL/QgEmOKDl7d1SqNvdPZEfbL
2gCDa1GXOCn165H0YJ07dGWAGyEjlI2jfmw5grvX/ujFI1hyoS809opb3zHSDf1a
/SxTLnBOBOwP0/p+D5mJavf4FXRi8bsXi+6YxYzO+12e8UmQemGjhveoFlXCt88r
Xo4pqMHEp9jIQTSwX4XebbOQRUjQb+INAYpmxL56Cpih4p1hGrRs2er9G2m/Dnrr
JZ+ReL8HYTt0yaTaTwWi+OzcKSQzGgCMeMAX8MRgbGNp/1hBtIihYSwxAgGB4Uv6
roTmLYHvGMb+8vGvOZKO
=fVGl
-END PGP SIGNATURE-

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

Re: [qubes-devel] Changing qubes-core-admin license to LGPL v2.1+

[Rusty Bird]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

Marek Marczykowski-Górecki:
> Dear Qubes Contributors,
> 
> In the process of developing commercial extensions[1], we may need to
> interface them directly with Qubes core scripts. While our goal is to
> keep Qubes OS itself as open source, this may not apply to some
> commercial extensions. The majority of commercial components can be
> implemented as standalone applications (qrexec services, etc.) and
> specific configurations (including salt state files). But some of them
> may need to interface with core Qubes code directly (proverbial "import
> qubes" in Python). Doing this with the qubes-core-admin component,
> which is licensed under GPL, would force such an extension to be
> licensed under GPL also. In many cases, we may decide to do this anyway,
> but we'd prefer not to force this (on ourselves or anyone else).
> 
> We have three goals here:
>  - Keep core Qubes OS code open source
>  - Allow proprietary extensions
>  - Find ways for Qubes OS to survive and grow
> 
> In order to achieve those goals, we'd like to change the
> qubes-core-admin component license in Qubes 4.0 to "LGPLv2.1 (or later)".
> License text is here:
> 
> https://www.gnu.org/licenses/old-licenses/lgpl-2.1.en.html
> 
> To do so, we must ask everyone who contributed code used in qubes-core-admin 
> in
> Qubes 4.0 to accept this change. Here is the list of contributors:
> 
> - Andrew David Wong (Axon)
> - Bahtiar `kalkin-` Gadimov
> - Desobediente Civil
> - HW42
> - Ivan Konov
> - Jasper Tron
> - Jeepler
> - Jon Griffiths
> - Mario Geckler
> - Michal Rostecki
> - Nicklaus McClendon
> - Olivier Médoc
> - o
> - Patrick Schleizer
> - Joonas Lehtonen
> - qubesuser
> - Manuel Amador (Rudd-O)
> - Rusty Bird
> - ttasket
> - Unman
> - Victor Lopez
> - Vít Šesták
> - Zrubi
> 
> If you are on this list, and you agree to the license change, please reply to 
> this email with a simple "I agree."
> If you signed your patch(es), we would strongly prefer that you use the same 
> key to sign your reply.
> 
> *Important!*
> 
> Ideally, we would like to get consent from everyone on this list
> before proceeding with this change. However, it is possible that
> one or more people on this list will not reply (e.g. because we do
> not have a working email address for them, or they no longer check
> the address we have). Therefore, we are adopting the following
> policy: *If you do not reply with one month, we will assume that
> you consent to this change.* (If you need more time to decide,
> simply reply within one month to tell us that you need more time.)
> 
> [1] https://www.qubes-os.org/news/2016/11/30/qubes-commercialization/

I agree.

Rusty
-BEGIN PGP SIGNATURE-

iQJ8BAEBCgBmBQJZbeiEXxSAAC4AKGlzc3Vlci1mcHJAbm90YXRpb25zLm9w
ZW5wZ3AuZmlmdGhob3JzZW1hbi5uZXQ4NEI1OUJDRkM2MkIxMjlGRTFCMDZEMDQ0
NjlENzhGNDdBQUYyQURGAAoJEEadePR6ryrftTgP/je6cL9i+UgCqJfIkeNKlZ1d
98W62soaF+RdtD9BRZEJZIXfQi1tprJ3ICr4IWIlgDG9U8m9G/KESPnQhdhJregn
Wv0Bs5XZFT/wh0A+9EZv5vitNDzbeUxozYxpG5tMC4XPvPbDQV+BrOSNxe9Jf61k
pnTAsqF3hmghEaRPhXc/M4NUcL2aLheL6bNTV2YIDXjBK5KPCurPCLYNqNupDMah
HZzESFldAjZgiqctxL97hN0WRzeB5bSvZJb56AU9iduyq95Ei7b8D4OFGaNkQZpK
a9DJaXdXBIbsiYAohvRVAzL0GtF75F+hnMBMkUVpAnbOwVvidpdNyxKkMs12H5cI
N+AaACigsz4VQhquYRc3HVznY4X/pIr77k6HKstD7wV8gDbjlPOj3cSF9UiigXY2
i2w1f5CtnqcqsbBqNvpTA6P06ykJZ+8AQBHafD91ASA8duCj5HfSKLZr51zs0pyj
qidy9MOGOujMKRSeEmRZtmlezUYwuxcV3EPbHVNzpS9VhormDe7oNPtA5AuciiUb
mxP9zEWJ0aRL456+GAY8GShs0DV+UY/eiRnf9dhCN1LHcFGJF4Y+ZpJW3N8KBYM+
M3jx8c5fWfc4s71sRXa1ACRu/37+jBqL92FxLa+PHdDmfYlYGrtjyhHPDHCPPGFA
c5dyZ/vbMa3Ll4p+L2DG
=py3n
-END PGP SIGNATURE-

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

Re: [qubes-devel] [GSoC] Progress report: Anti Evil Maid enhancements

[Rusty Bird]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

Hi Patrik!

> On 07/05/2017 05:30 PM, Rusty Bird wrote:
> > How should portable Qubes installations be handled? We can't save
> > the owner password in the initramfs. But I was thinking, the
> > function to write a 256 bit value to NVRAM (at index n) can be used
> > to store not only the hashed freshness tokens for every AEM device
> > (at index 1, 2, 3, ...), but also a randomly generated TPM
> > identifier (at index 0) that could actually replace all the
> > tpm_getpubek stuff in tpm_id.
> 
> Assuming "portable Qubes installation" means sharing a storage media
> containing installed Qubes OS between multiple machines --

Yes, exactly that.

> we could
> store a TPM (UU)ID to {owner,NVRAM} password mapping on the portable
> encrypted root disk instead of a single password; plus per-machine
> (per-TPM, rather) sealed AEM secrets (which in the current
> implementation would get mixed up and overwrite each other if TPM has
> owner password set up, but otherwise works already -- simply replacing
> tpm_id with something not relying on pubEK will fix this, more below).
>
> Neither the owner password nor the NVRAM area password are stored in
> the initramfs, as that would be a security risk. They are stored only
> on the encrypted root partition.
> 
> The TPM 1.2 spec mandates at least 512 bytes of NVRAM storage to be
> available

1280 bytes? [1]

> (actual storage is vendor-specific, no upper bound given).
> Assuming 20 bytes per (sha1) hash that's only 25 values in the worst
> case -- and this space is shared between all "applications", so Qubes
> AEM should probably not take up all of it.
> 
> So far I've thought about storing a unique 20-byte value as a TPM
> identifier (a randomly generated UUID hashed with sha1)

Or just 'head -c 20 /dev/random' instead of 'uuidgen'.

> and reserving
> a few (say 2 or 4) 20-byte slots for freshness tokens, so that you
> could have MFA-protected backup AEM stick(s). That's just 60-100
> bytes. In principle similar to LUKS key slots stored in its header
> (which has space for 8 keys).
> 
> What do you think?

You probably don't even have to define a maximum number of slots in
advance -- the TPM ID / AEM freshness tokens could start from some
constant NVRAM base address and (attempt to) go as high as needed. If
anyone really wants to manage a ridiculous number of AEM devices, why
not let them try. :)

Rusty


1. 
https://trustedcomputinggroup.org/wp-content/uploads/TCG_PCClientTPMSpecification_1-20_1-00_FINAL.pdf
   (bottom of page 14)
-BEGIN PGP SIGNATURE-

iQJ8BAEBCgBmBQJZZMuaXxSAAC4AKGlzc3Vlci1mcHJAbm90YXRpb25zLm9w
ZW5wZ3AuZmlmdGhob3JzZW1hbi5uZXQ4NEI1OUJDRkM2MkIxMjlGRTFCMDZEMDQ0
NjlENzhGNDdBQUYyQURGAAoJEEadePR6ryrfSNEP/jdYH7xcuf3TRxRyJGZuPRaV
Mkk+hHWBvTOlIatFUFZL987HexzSeZNR5QRk5xIUaCtwYVKEHb8/mI5ySPrUJCy5
LFeGGIRURFPsSePym+MwXXElcAzL1fTBbOEkkARtP2vyrfCt4w4OCHeDDF3MvheM
kWCOkZTHD+zzSqPzx+gs7lP80eYhXTNLZIMs/UcqRJA+aFmpxdf5KfcnoL9UjggE
iXBtPdL2gLu3S1M/h9CcHObpJusJ98GSmIQjSAcI44mLQdD5fONfDohpTVuXoG81
uYVdbZFDDCt26+ow2m+J+e1Qc/CsE7W42pRfEoD8We9I2wsGUya1fF8sGR8Nj89K
rAPuJeP+Os/THs+7yf3IsjeSJd8j9QX+4iZO6K5WVqosfakFu4Vk0rOlj6e2KoqM
8kWC251q06bT18+nZ9DwQuJ+Ua7gmX5AE6i9APWeTaOk6bFjp49fZO6TEhIlKv3y
EdJjqk4NTAR2LvmkECkWn0BZYWOPAE8hnIZwVJaf5r1US8O3zzOb7DE5G7MwizpW
ClxJAS82t3JFZLkgw3JuILROqhSe3QFXFY+CR1Q3jyIiX8lvaW5gk4lAICNrMWr6
LK9eA6E/9UQ4/J3bXimrtBhIyM7+hVdtTqLXZkyTSozkwh17kAf+PzE/5hen+SEr
IrhjZxQlOnRq7RpWGcKd
=MPqD
-END PGP SIGNATURE-

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

Re: [qubes-devel] [GSoC] Progress report: Anti Evil Maid enhancements

[Rusty Bird]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

Patrik Hagara:
> On 07/04/2017 12:28 AM, Rusty Bird wrote:
> > Hi Patrik!
> >> OK, let's go with the freshness token then.
> > 
> > To avoid implementation complexity here: What do you think about 
> > unconditionally requiring the freshness token in all AEM setups,
> > and (as a stretch goal) skipping the token _update_, both on the
> > AEM medium and in NVRAM, if the medium is read-only? IMO it's not
> > crucial to implement this read-only check in AEM 4.0.
> 
> Hmm, that could work.

How should portable Qubes installations be handled? We can't save the
owner password in the initramfs. But I was thinking, the function to
write a 256 bit value to NVRAM (at index n) can be used to store not
only the hashed freshness tokens for every AEM device (at index 1, 2,
3, ...), but also a randomly generated TPM identifier (at index 0)
that could actually replace all the tpm_getpubek stuff in tpm_id.

> > Inside of the anti-evil-maid-(un)seal.service systemd units,
> > /dev/tty is already inaccessible, so 'echo password | tpm_whatever'
> > should work. (When the anti-evil-maid-seal script is invoked
> > manually, the 'echo password' input will be ignored and
> > tpm_whatever will display its own prompt.) See e.g. the
> > tpm_sealdata commands in the (un)sealing code.
> 
> Oh, right! Somehow I missed this fact (/dev/tty inaccessible in
> services). Still, the workflow outlined right below is IMO better
> (perhaps as a stretch goal?).
> 
> >> Reading the TPM 1.2 spec again, I've noticed there's a way to
> >> delegate owner's authority for execution of (a specific subset
> >> of) owner-only TPM commands (ie. generate a new password that
> >> would only be usable for resetting the DA lock and nothing else).
> >> While there's no tool for that in tpm-tools package, it should
> >> not be that hard to write one using the TSS API provided by
> >> TrouSerS. Additionally, this would get rid of the /dev/tty issue
> >> and reduce the impact of potential password leak -- only this
> >> limited password will be stored on (encrypted) disk, not the
> >> full owner pw.

Conceptually, it's cleaner for sure. But I don't know if that makes it
worth the extra C code. If an attacker can access the encrypted disk
contents, the TPM owner password would probably be low on the list of
things to worry about?

Rusty
-BEGIN PGP SIGNATURE-

iQJ8BAEBCgBmBQJZXQYGXxSAAC4AKGlzc3Vlci1mcHJAbm90YXRpb25zLm9w
ZW5wZ3AuZmlmdGhob3JzZW1hbi5uZXQ4NEI1OUJDRkM2MkIxMjlGRTFCMDZEMDQ0
NjlENzhGNDdBQUYyQURGAAoJEEadePR6ryrfk08P/A2F7FlABf7JCjmHmIdYlpfj
KNglHY53bt9JVksWmpXCqkeGjH2KVeqRtWAR9tbM9BeQktPDQCYY+PWv+oYSwSnT
8fYh4oHKlcc85adhHMYOFbfo7n4tqlTcsBdk4oFnlp1DDEZkKC+QwwPmIUfM+edz
uNvChVsU+V7nwgWBVgY7x1R08AcW/3pPXRUNF+MwjDyeXVCh0TxYI5zYJc5HLMiK
2kjQ8R1TFXriyVvJceC+9IVvJ5Kr/3KqshapCtUiGUG0KybM3RFPLvc5RXuG1aTO
hNhrfUs+VKTlrdD8TJAG2Amv0NTP6JGl+x2Evol2sT8/IwCJME6nJIBZfD+5AGm1
bffsApo8/2bxHTpwC8nP7vzT7WqNf1xvIktYzM+0vysdctKhuONoSbs+GYSZuQhp
6d51+fgZz1DX6sXrxsu9D+F6Qp7DFIZSiwzTdigIQ9cydyHNO2sD5iD0KR8Yl1Dn
7f+koFAgU4AOlNS0RBNXD3yHgx/Opr/WhTv3QQLkD88POzfJ9dIpWXo3GGgZ5qe7
AIZaw7tyLN4zTocXghx8ewbxTaE7CgqzceyCckjKcL/ajyEubq0a6LzwUlhVaL7u
VxmbQwMiPqaep18SSByhr3CFh/nfUg/4PaHbZDbgA7xQcHAPRRdPPbkGOjICY4Pe
D78wH8yzONOmH0k/HUyY
=VMqd
-END PGP SIGNATURE-

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

Re: [qubes-devel] [GSoC] Progress report: Anti Evil Maid enhancements

[Rusty Bird]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

Hi Patrik!

I just noticed that qubes-devel seems to break your PGP/MIME
signatures. Inline PGP works better on Google Groups based mailing
lists. (The CCs have all been fine, of course.)

> On 06/26/2017 05:28 PM, Rusty Bird wrote:
> >>>> I guess your last point is valid, we can seal the actual secrets
> >>>> (txt/png/keyfile) just once and always reseal only the "freshness"
> >>>> token. I'll have to think more about this, but so far I didn't find any
> >>>> obvious flaw with this approach.
> >>>
> >>>> As for the DMA attack mentioned in your later e-mail, shouldn't the
> >>>> IOMMU (which is required for Qubes 4.0) automatically protect against
> >>>> that (as it gets activated by Xen)?
> >>>
> >>> I might totally have the wrong picture here, but can't the rogue PCI
> >>> device (which would not be assigned to any VM) access all of dom0's
> >>> memory? [2] Or are there more fine-grained restrictions?
> > 
> >> You're probably right. In which case, encrypting the whole (not just
> >> dom0) RAM would most likely be the only option.
> > 
> >> Considering the ability of DMA to modify memory, unsealing the
> >> "freshness" token before the actual secrets would not provide any
> >> meaningful security and the resulting AEM code would be pretty similar
> >> in size anyway. :(
> > 
> > Reading memory (with a DMA attack, a cold boot attack on transplanted
> > RAM modules, or a cold boot attack in the same system if SCLEAN really
> > doesn't wipe all memory) still seems like it could sometimes be more
> > straightforward than writing memory (with a DMA attack). And it's kind
> > of neat to be able to protect text secrets, in the absence of these
> > memory attacks.
> > 
> > I don't know. But we can always revisit the whole separate freshness
> > secret thing later. Maybe somebody will weigh in on read-only media
> > support in the meantime?
> 
> OK, let's go with the freshness token then.

To avoid implementation complexity here: What do you think about
unconditionally requiring the freshness token in all AEM setups, and
(as a stretch goal) skipping the token _update_, both on the AEM
medium and in NVRAM, if the medium is read-only? IMO it's not crucial
to implement this read-only check in AEM 4.0.

> >> One significant issue I've encountered this week is that the TPM
> >> dictionary attack lock actually triggers after a few reboots (due to
> >> tpm_id and tpm_resetdalock calls with well-known owner secret)...
> > 
> > Would removing the 'tpm_resetdalock -z' calls in -unseal and tpm_z_srk
> > improve the situation? Looks like it's counter-productive in setups
> > with an owner password.
> 
> There's also the tcsd_changer_identify scripts with call to tpm_id which
> gets executed every time the tcsd service is starting (via ExecStartPre
> tcsd.service unit drop-in). The tcsd_changer_migrate drop-in will also
> call tcsd_changer_identify itself if not already migrated. That's one or
> two tpm_id calls which contribute to dictionary attack lock. And I see
> no way to get rid of this completely. :-\
> 
> 
> Anyway, why should having a non-zero owner password prevent you, a local
> user, from reading the TPM's public endorsement key? TCG claims it's due
> to anonymity concerns (as the pubEK uniquely identifies the TPM), but
> the same can be done by querying (via /sys or whatever) the serial
> number of any other HW component (mobo, HDD, battery, ...) or just the
> specific HW configuration/topology (model numbers, which bus/port the
> devices are connected to, etc.). It makes sense for remote attestation
> (and the spec already has a Direct Anonymous Attestation protocol to
> solve this) but not much for local usage.
> 
> 
> > Also, -seal could avoid the tpm_z_srk call if $CACHE_DIR exists, and
> > in this case set $Z based on whether $SRK_PASSWORD_CACHE exists.
> 
> Yeah, I'd rather just call tpm_resetdalock here with a password read
> from the (now unlocked) disk...

Sounds good.

> > If it turns out to be necessary, TPM utilities can read from stdin --
> > but only when /dev/tty is inaccessible (like in a systemd context):
> > 
> > # mv /dev/tty{,.bak}; echo password | tpm_whatever; mv /dev/tty{.bak,}
> 
> That's... not nice.

I forgot to mention that this line is only for testing!

Inside of the anti-evil-maid-(un)seal.service systemd units, /dev/tty
is already inaccessible, so 'echo password | tpm_whatever' should
work. (When the anti-evil-maid-seal script is invoked manually, the

Re: [qubes-devel] Re: [GSoC] Progress report: Anti Evil Maid enhancements

[Rusty Bird]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

Andrew Morgan:
> (For some reason your reply doesn't show up in mailing list, so replying
> with it quoted below)

Ah what is the matter with Google Groups and my e-mail address.

> Heh, I need to stop replying to emails in the wee hours of the
> morning... Thought you just needed a script tested or whatnot.
> 
> That being said, while it is my main work laptop, t if all that happened
> was the RAM cracked it wouldn't be too expensive to replace. Anything
> else would be bad though, since I'm doing my own GSoC project on here :P

I probably wouldn't try this with my main system. There could be other
issues, such as condensation.

> What may be tricky is what to do after the DRAM contents have
> been frozen. Does one just plug it in to a running Desktop system and
> execute some software to scan the contents?

For the SCLEAN test, it would all happen inside a single notebook:

1. Boot in AEM mode, without dom0_mem=max:4096
2. Turn off swap space and shut down all VMs
3. Run some small program in dom0 that allocates as much memory as
   possible and fills it with a pattern
4. Cool down RAM modules, unplug disk, and power cycle
5. Boot memory scraper from another disk, and see if the pattern is
   still present - if it is, SCLEAN has been ineffective

> This article states that cold boot attacks against DDR3 systems are
> much less feasible than DDR1/2. Would it even work if we tried?
> 
> https://darkwebnews.com/security-guide/cold-boot-attacks-unencrypted-ram
> -extraction/

With t=0 seconds between power off and power on (what they call "warm
reset" in the quoted paper [1]), they say it worked even with DDR3
RAM. But it's good to know that transplanting DDR3 RAM turned out to
be pointless! Thanks for the link.

Rusty


1. https://www1.cs.fau.de/filepool/projects/coldboot/fares_coldboot.pdf
-BEGIN PGP SIGNATURE-

iQJ8BAEBCgBmBQJZVAEBXxSAAC4AKGlzc3Vlci1mcHJAbm90YXRpb25zLm9w
ZW5wZ3AuZmlmdGhob3JzZW1hbi5uZXQ4NEI1OUJDRkM2MkIxMjlGRTFCMDZEMDQ0
NjlENzhGNDdBQUYyQURGAAoJEEadePR6ryrfaGQP/3sZguIoGBYlV0XklUvd2VYM
po6okxWjvmAh35d/TRFvkIkKVLmCmq62+kZ2HQDhjebuQm4se+9TJDphyhUHecDx
IVjIZei68F+ln9ziTBPz4ctymTmDZjdEO9NFeKv/ZQqgmOZvr2JNN+wKJKz/T57b
vnvLyp2ubb+oXQ+wJ3NcGudnhjQqbDYsgQmWCkXmUcMsI3BT/4KHNB1SDgpvmDBk
8ic6/ViyrZXqsJSZf7qZOT2dZ+5OcBSZgYp6MKRRsCo3vJOqKfSscr+f3QCdnU5I
HlBEgoWIkiSWLLOxcNYUvksUHy52kz3vr24TmYgK0G0ewblqKQeem/7PJCIZJ2M3
FZC0Q2E2Tzj7BLL4Rfdkyh+O/EDMiwI43Qr1was9bADQ/L2z8qMlsODafzb6pz+X
5KDf9gNJRjOGUV+r6I39PCz9TLO+zrBNUUJCVC8C8CL0fKHy06EPh0m9LXxehDt1
bwHR3vPFMj4+87MoWH+fWgqkogEM+VVoNTTaxOWM2jPF2EJ4bje7MxCfOdb2+qqM
7MBpBJVoQ7YRhVxtWGMOmJN3EkijajD3scEpaN9Li8mAh8PzFdvOTXFzXehOVUma
usvUzPf0nJmFkDL1q/K1tL5RyEgLvH/ypZPs65ArOJNDlBhBQI3wfucHDLMDWUNG
K6BZSGXO+IE1bkqcrVME
=bvnr
-END PGP SIGNATURE-

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

Re: [qubes-devel] [GSoC] Progress report: Anti Evil Maid enhancements

[Rusty Bird]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

Hi Patrik,

> On 06/19/2017 12:43 PM, Rusty Bird wrote:
> > Patrik Hagara:
> >> On 06/18/2017 05:51 PM, Rusty Bird wrote:
> >>> Rusty Bird:
> >>>> Patrik Hagara:
> >>>>> Single-use key file code committed
> >>>
> >>>> Whee, I finally get it... Seeing how it all fits together, it looks
> >>>> really cool!
> >>>
> >>>> What do you think about making replay protection a self-contained
> >>>> secret? If we'd change it from a counter (shared between the combined
> >>>> counter+keyfile secret and NVRAM) to a per-boot random string stored
> >>>> in a separate secret.fresh[.sealed] file, and stored in NVRAM _as a
> >>>> hash_ -- then AFAICT the attacker still wouldn't be able to malleate
> >>>> the secret in any meaningful way, and:
> >>>
> >>>> - secret.fresh.sealed (the first to be unsealed) could be used to
> >>>>   replay-protect all types of AEM secrets, not just keyfiles
> >>>
> >>>> - If secret.fresh.sealed is in fact stale, the keyfile would never
> >>>>   have to be unsealed into memory, where it's susceptible to a cold
> >>>>   boot attack (probably even if the tmpfs file is shredded, due to
> >>>>   buffers)
> >>>
> >>>> - It seems like this approach should simplify the implementation? No
> >>>>   concat/split code, fewer special cases (e.g. all AEM setups would
> >>>>   have the same always-reseal workflow)
> >>>
> >>> Hmm, replay protection would be incompatible with the use case in
> >>> which a backup AEM stick is stashed away somewhere. So it probably
> >>> shouldn't be enabled in non-MFA setups after all, or at least not
> >>> unconditionally.
> > 
> >> Anti-replay secrets could be compatible even with backup AEM sticks,
> >> just by having separate secrets for each AEM device.
> > 
> > Oh, right! NVRAM has enough space.
> > 
> >> However, always resealing would not work for read-only media.
> > 
> > And read-only media could theoretically become more attractive in R4, if
> > hypervisor vulnerabilities (=> updates => resealing) are going to affect
> > Qubes less frequently.
> > 
> > OTOH, making replay protection _optional_ would complicate the code yet
> > again. For example, tagging a particular text secret as "don't display
> > if secret.fresh.sealed is missing", similar to the current counter +
> > keyfile concatenation.
> > 
> > :/
> > 
> >> For cold boot attacks, a good solution would be to encrypt the whole
> >> memory using eg. TRESOR (storing encryption key in CPU debug registers),
> >> with no perceptible performance penalty on Qubes 4.0 compatible CPUs, as
> >> most/all Intel processors with VT-d also have AES-NI. Not sure whether
> >> encrypting RAM from Linux would be enough or whether we would need to
> >> implement the encryption in earlier boot stage (tboot or Xen).
> > 
> > There's an old ticket [1] for TRESOR -- targeting disk encryption keys
> > only, but even that is "far in the future"...
> 
> I've read some more about Intel TXT and tboot... and it seems that cold
> boot attacks could be ruled out as any abrupt shutdown will trigger a
> secure RAM scrub (via BIOS ACM, a different thing from the SINIT ACM
> module). However, I'm not 100% sure whether whole RAM gets wiped or just
> the TXT-related bits -- couldn't find that explicitly stated in neither
> TXT nor tboot docs. :-\
> 
> And since the BIOS ACM is a binary blob, the only way to find out will
> be to actually perform a cold boot attack...

Yes, it would be interesting to test this on e.g. a popular ThinkPad
with 16 GB RAM. There are some bootable memory scrapers [1] if anyone
doesn't know what to do with all their liquid nitrogen...

> >> I guess your last point is valid, we can seal the actual secrets
> >> (txt/png/keyfile) just once and always reseal only the "freshness"
> >> token. I'll have to think more about this, but so far I didn't find any
> >> obvious flaw with this approach.
> > 
> >> As for the DMA attack mentioned in your later e-mail, shouldn't the
> >> IOMMU (which is required for Qubes 4.0) automatically protect against
> >> that (as it gets activated by Xen)?
> > 
> > I might totally have the wrong picture here, but can't the rogue PCI
> > device (which would not be assigned t

Re: [qubes-devel] [GSoC] Progress report: Anti Evil Maid enhancements

[Rusty Bird]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

Patrik Hagara:
> The initramfs would, upon next boot, read both the sealed LUKS key file
> (unsealing it, along with stored counter value) and the publicly
> readable counter value from TPM -- and, assuming the values match,
> continue booting. An attacker cannot circumvent this check -- changing
> the code will result in different PCR hash and thus the key file failing
> to unseal.

One possible attack would be to patch out this check in memory as soon
as the kernel has started up, i.e. after SINIT has already measured the
initramfs, using DMA from a malicious PCI (ExpressCard, Thunderbolt)
device. Similar to TRESOR-HUNT [1], in spirit.

But I don't think this invalidates your implementation, which at least
requires the attacker to have such a device at hand.

Rusty


1. http://old.iseclab.org/papers/acsac2012dma.pdf
-BEGIN PGP SIGNATURE-

iQJ8BAEBCgBmBQJZRtO+XxSAAC4AKGlzc3Vlci1mcHJAbm90YXRpb25zLm9w
ZW5wZ3AuZmlmdGhob3JzZW1hbi5uZXQ4NEI1OUJDRkM2MkIxMjlGRTFCMDZEMDQ0
NjlENzhGNDdBQUYyQURGAAoJEEadePR6ryrfJgYP/3KQ3OkTteHGTqMX7Rj7NLhI
8P6s6xHSXOkd2jTK9Ss4bT3aCSsoYPUcOXrUSRf/wYhPCuIqP9OXCpOxyzC2V567
VnTzjCEEt27W/F43skNRygRVIIfkw7OBFNpHPgj9HkeaDprM4csI3mQ0wElIMx7Y
cL+f0ymSFTJCL5G4/sfhzixVmL+yjDbZYjDoIaiI8no563t6DVvz2UdjpF5vEpX2
gyj1InqTJ0aiHrGPDTGnVQbZ5SbIFCcAW5gIL50cW7RVbw3xHGo5lgR3hHtx0hn/
6fvhrFCJIxhJCba1NmDQ5uz6Ybjr1AU2Dx4fr+SQ/TKtkSCaZ1cu6vpg+mCjJxQb
v8ZLRsQDkcE8k9diLCXyQcXVkLBKdX+xJMnem0+y2VEdgd86lr8HK45uptrtwsWe
aepeyHZlbem4qBZA4pzIdAwHPfbZzH3oQCcGRkdspBpS7Ls2BMUf38HJklM+MVPO
fMFVUM2peEpmpzsdumJcS3RlF/VpQT5fzZwbPxhQMRmJnJyvfRvh+9BqRDRus0SC
Lifp8k3ldhzh3U+VWcRH5N64wDUaEIpBwbrj+SNuHwVYWggsY1aDFNIwdyFCCJne
fbc+ovHRKSrzC2xcWVsXtDQnxieHqX9oXWd7BGh/CfUcddXcHQ/L2o5qi4FTnX5p
qfkOdzlliBvDp0UPVQQg
=wHwZ
-END PGP SIGNATURE-

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

Re: [qubes-devel] AEM: Should we drop .png support?

[Rusty Bird]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

Marek Marczykowski-Górecki:
> I think PNG support is a nice half-measure against shoulder surfing -
> details on the image are harder to copy/remember (or even photograph
> with a small camera), than some text.

You're right, it is better. I hadn't considered that the user can
manually clear the image from screen as soon as they've recognized it,
simply by pressing Esc to switch to text mode.

> When we get some better alternative, we can drop PNG.

Sounds good.

Rusty
-BEGIN PGP SIGNATURE-

iQJ8BAEBCgBmBQJZRtGEXxSAAC4AKGlzc3Vlci1mcHJAbm90YXRpb25zLm9w
ZW5wZ3AuZmlmdGhob3JzZW1hbi5uZXQ4NEI1OUJDRkM2MkIxMjlGRTFCMDZEMDQ0
NjlENzhGNDdBQUYyQURGAAoJEEadePR6ryrfltsP/3prk/o8c3k/5F0E6pOVuzFb
JIrfc2Vct0Ai/LbUX9OlwNGKBlxZbUv/KoxrxPWnOXT5YUEmXRBOkKneZsOeGYk1
OleLQ4A2SJaq5+e4WTRvSY6nk+i9LswMMvTkWCi/2zNo08HMGdmHUpE3vmNkp+uJ
5OwCmR4pIbQ4hrQN+MWJPHXtz6NMmvksoB8OgSBEIULqtU0Hp5kijxW416kNi86q
sknnfk/kj7mnanQW9IRkmkiQ740RJP/1lQ93khrBdF2H+4Ue0g2PvxkMohVNWgGm
kfkVYjAeu3zVnLpsXsbtLu9VpMQ+xNFXY32rfm9kzg+X65Pd3GfTEj+IqdcV04ST
MhQ3KSuoZlyX6Tfk4jmd4acBHrWgSEwSB8NlsgK3qWxMn+NuAfEilQm4awYtwedw
ItpUTUcqDFg02nMfyfY3kvhnm2JjeIEVc4VrrB1452Tg/5exu+j1DyqLLHFd8WvY
KdmN0Gddfe70JZYB1fmutWF7OCY4FYMBi177avstVeAqlhC6Aa9UNJtSu88jrmdm
fnDpS3LS4anrjj3+OxLxJZJeJ3SNO6M16rhEIf81Y6FGzy+X3TOECBDsKGdycwNR
0FZM19X+8+8koQEUPt8ZxBZC6AphTpX1GNKXBzrWTovzflNUDiNklZm6DQU0rDhc
nR+E4brBA+9dfqPdkMg/
=TDgE
-END PGP SIGNATURE-

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

Re: [qubes-devel] [GSoC] Progress report: Anti Evil Maid enhancements

[Rusty Bird]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

Rusty Bird:
> Patrik Hagara:
> > Single-use key file code committed
> 
> Whee, I finally get it... Seeing how it all fits together, it looks
> really cool!
> 
> What do you think about making replay protection a self-contained
> secret? If we'd change it from a counter (shared between the combined
> counter+keyfile secret and NVRAM) to a per-boot random string stored
> in a separate secret.fresh[.sealed] file, and stored in NVRAM _as a
> hash_ -- then AFAICT the attacker still wouldn't be able to malleate
> the secret in any meaningful way, and:
> 
> - secret.fresh.sealed (the first to be unsealed) could be used to
>   replay-protect all types of AEM secrets, not just keyfiles
> 
> - If secret.fresh.sealed is in fact stale, the keyfile would never
>   have to be unsealed into memory, where it's susceptible to a cold
>   boot attack (probably even if the tmpfs file is shredded, due to
>   buffers)
> 
> - It seems like this approach should simplify the implementation? No
>   concat/split code, fewer special cases (e.g. all AEM setups would
>   have the same always-reseal workflow)

Hmm, replay protection would be incompatible with the use case in
which a backup AEM stick is stashed away somewhere. So it probably
shouldn't be enabled in non-MFA setups after all, or at least not
unconditionally.

Rusty
-BEGIN PGP SIGNATURE-

iQJ8BAEBCgBmBQJZRqF6XxSAAC4AKGlzc3Vlci1mcHJAbm90YXRpb25zLm9w
ZW5wZ3AuZmlmdGhob3JzZW1hbi5uZXQ4NEI1OUJDRkM2MkIxMjlGRTFCMDZEMDQ0
NjlENzhGNDdBQUYyQURGAAoJEEadePR6ryrflCQP/i4NBM8yXNzZ9jLrMxpbwiUz
nw3zWkm/NrjTEE6lWob7dFS8CN8lMkapt3x7fx90uky0XGcsNVSfghxcF+yjaOuo
Ni9wuvkfCAYDfrcTaUHZV2M21sHlxIM+dagmZqMPFlJt9LTu6Ju0P+nExQvZ7C0w
ZM7h2MFX7X89g+ESo5j/ZQQwghXh9NTOjpxC4UUTfsWwyCLROmrvmbvpWBwUa7m3
nWAfFL1qUnIENtrlHvq/fKmkIVpVRHmU8Gbhy1u5wH23aTAk5XqGBriw2HM7WdML
oS37e15uymf4TxqSl9Ehwc9gHdLHrWVaEgImrIc1buEQZppSl3iQy98YGP3FfpWQ
qEwrURqHc45r4gfz2VwRo6XTJ18tgL7dGr+JfQJIY3pwQO4SSdL9ZPSPIITdlR9C
zoe33FCqdg1HlcW+PLAVV8MV3KKaSilxI1wGRinhYKQUpKvnOnmUQRjMBZNY2o+9
xqFsLIfglhUzE4u9noE1IREudWSB+hBaFRncAdg7SgZOvV9oEJsVYA+rVdF9reBA
1oUo37qShLMfD9Cilos/hgvO5hJ+41VND3GFyhrhoQ6b/25PmnhVIEAWXLtPWj7V
mdaHVqYaHK/p/eDfeHCiPBHMAGrFk+97cnD2wW+Ds7vQGufvxDbiK73zSFK+sMCq
VyqfZcTnHUygcP26Dm+U
=rDb3
-END PGP SIGNATURE-

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

Re: [qubes-devel] [GSoC] Progress report: Anti Evil Maid enhancements

[Rusty Bird]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

Patrik Hagara:
> Single-use key file code committed

Whee, I finally get it... Seeing how it all fits together, it looks
really cool!

What do you think about making replay protection a self-contained
secret? If we'd change it from a counter (shared between the combined
counter+keyfile secret and NVRAM) to a per-boot random string stored
in a separate secret.fresh[.sealed] file, and stored in NVRAM _as a
hash_ -- then AFAICT the attacker still wouldn't be able to malleate
the secret in any meaningful way, and:

- - secret.fresh.sealed (the first to be unsealed) could be used to
  replay-protect all types of AEM secrets, not just keyfiles

- - If secret.fresh.sealed is in fact stale, the keyfile would never
  have to be unsealed into memory, where it's susceptible to a cold
  boot attack (probably even if the tmpfs file is shredded, due to
  buffers)

- - It seems like this approach should simplify the implementation? No
  concat/split code, fewer special cases (e.g. all AEM setups would
  have the same always-reseal workflow)

Rusty
-BEGIN PGP SIGNATURE-

iQJ8BAEBCgBmBQJZRpsMXxSAAC4AKGlzc3Vlci1mcHJAbm90YXRpb25zLm9w
ZW5wZ3AuZmlmdGhob3JzZW1hbi5uZXQ4NEI1OUJDRkM2MkIxMjlGRTFCMDZEMDQ0
NjlENzhGNDdBQUYyQURGAAoJEEadePR6ryrfwXMP/3e3eas+5uDtq98w5A+fwW+W
A56dVp/e1e8TqsumtHxlmo3rZ2IF6nfvFwjwcKAvQ200KTj0nBvBposXXM5GD2i0
hskpLzEkq2Dapbgnyqd9RWUiQ57ieOWg5qXJmS61q4q9njTgSbIhtnyxgFczqmAb
nwc6q/H2eAia4hE0A40aMKOby8T89l4VYo0Czipz8zEZqGtnRRI2yCyhDZLu+eR8
raV9kggH6g/oJjmr+jTnOx1SHUFSVieOns4RfzoaTxV0y86TPknc5QG80/IheP3d
AqvEUd6P4MYdngZoL7Txwh0VNE4WwK8qn64bPX27jEJIXZuWxn01P9rQee2dYAJZ
SD4JG5/NtYBCopFmZJ2zZ54PjfreO/SoUrlk6CB2ZKF/JLc91qi/2xsrYZIwSPCj
Bdr84aUhb3T5I9kBaLM6eX19CZeqFa2bzSfSa1IedS5lqUcGnJddn2zHn3PSjUBp
9g1AVEkF9fhHjPvdBHmHYiyKRMDLW7+FzdCSNNt2vocfGNJu4fyNdGl2AYanuUrk
BjhnP+lotYtAUzIwH+l+SX9HhxWF0uBT/7pjj7rFwvs6Ku4LvUXYDFDkEL1DB6ep
fDDxuCzSt2iaMNiWKOvTk0YVrotWeuFXi3TAvgKYgozJqPdjeUzOqZPzsWJTxS43
1FSOyp4hlxs8lxu4JIeC
=VnBP
-END PGP SIGNATURE-

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

[qubes-devel] AEM: Should we drop .png support?

[Rusty Bird]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

Hi everyone,

What do you think about getting rid [1] of .png image secret support in
the next major version of Anti Evil Maid? This would offset some of the
increase in complexity incurred by the upcoming TOTP/keyfile support, in
addition to other benefits:

- - Considering that AEM is a security oriented feature, it's kind of bad
  to implicitly encourage the user to copy a complex image format from
  some VM to dom0 - where it will be parsed during boot. (It would be
  possible to build something [2] secure using the qubes.GetImageRGBA
  RPC service, but I don't know if anyone's particularly interested in
  working on that.)

- - .png support is hacky and weird: We show text secrets in the current
  dialog, but images appear in the *next* dialog. And text secrets are
  cleared from the screen as soon as possible, whereas image secrets
  stay visible until Plymouth finishes.

For users who prefer the more visual approach, we could tweak the
Plymouth theme to use a monospace font for text secrets. That should
make ASCII art a viable replacement for conventional images.

Rusty


1. 
https://github.com/rustybird/qubes-antievilmaid/commit/4e45af289d0e651a380f3182cb07901a3002905f

2. Similar to the WIP dom0 wallpaper service:
   https://github.com/QubesOS/qubes-issues/issues/215
-BEGIN PGP SIGNATURE-

iQJ8BAEBCgBmBQJZQ+FtXxSAAC4AKGlzc3Vlci1mcHJAbm90YXRpb25zLm9w
ZW5wZ3AuZmlmdGhob3JzZW1hbi5uZXQ4NEI1OUJDRkM2MkIxMjlGRTFCMDZEMDQ0
NjlENzhGNDdBQUYyQURGAAoJEEadePR6ryrfclYP/0zs3z4DcTOKPWwovD5Ly0VQ
LYBJsJE4VBqo2JOpdpArvf2i8nOGD5bkgTUKtPisS/0XLgEvurvGejFe0x6wlV13
HFhD42sHxWC65JxCyw1kS6bhnoYbIINiOneoyGikiStneiGqyzqz5ylEEdzPAkkP
Q7eXqbVBVfYBlfdrWNMNv6EPtdmBpkWU4c3EzJ9Qtm/StWGuhDxJgOKtzu10ZOi/
vJH5bIvhaNvbmNjqyT3OFlP2YLlqFZw2LHLH0x2cjmSEpQ0uUjQt+MCIowWqecYy
TgRTV9y5f7frS2SOEwwq8Wg+5OSryU8VanLb2nwGV8r4X0ro7dbkJ8++CzRVhi93
lrctzX9xcrfzGAD+3BSOvd6ZtxhquC2Ff9dHVSBc4fsCdgNBH5vXeWH4GiotGZP1
DxtQhuWIa6tZWwq9mhc/g8NYB0kVcgQ4fIQN2I7W09JtJuSiqx0txPwB6/S4Yw+o
gaMjmjr2Robi5gDBjouFNYRJSIWfhHTW89/bZakjub2nU2kvKQUqce/TwzBmAqGG
qBnDqUnre5pFTvN/hKZhbvIbfbOlPlc5EYxA1JqCUqoCEGb7sqLETDJc/HGcP8PV
kLfUTnoWU/dgnjJylKyxhH/pOQUbW2m8QqLoMZZcDK96xJ+YeCXm7iUEq3lfIq/8
59c9bYVCtoHd35x5c+kz
=em7I
-END PGP SIGNATURE-

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

Re: [qubes-devel] [GSoC] Progress report: Anti Evil Maid enhancements

[Rusty Bird]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

Patrik Hagara:
> Any and all code reviews are welcome! The changes I made are stored in
> my fork of AEM repository [1].

- - Please don't feel obligated to read this on a weekend :) -

One thing I noticed is that a comment in anti-evil-maid-unseal
mentions setting up /tmp/keyfile in /etc/crypttab. But adding the
kernel command line parameter "rd.luks.key=/tmp/keyfile" to
/etc/grub.d/19_linux_xen_tboot would have the advantage of working
even if dracut is in no-hostonly mode (e.g. on portable Qubes
installations), where /etc/crypttab is ignored.

There's a bug in systemd < 227, so to test this on R3.2 you'd either
have to patch [1] and rebuild systemd-cryptsetup-generator, or use
"rd.luks.key=YOUR-LUKS-UUID=/tmp/keyfile", which avoids the buggy code
path. But it won't be an issue on R4.0.

Rusty


1. 
https://github.com/systemd/systemd/commit/c802a7306bdc3e82378a87acd9402bbabe9f6b28
-BEGIN PGP SIGNATURE-

iQJ8BAEBCgBmBQJZPDYoXxSAAC4AKGlzc3Vlci1mcHJAbm90YXRpb25zLm9w
ZW5wZ3AuZmlmdGhob3JzZW1hbi5uZXQ4NEI1OUJDRkM2MkIxMjlGRTFCMDZEMDQ0
NjlENzhGNDdBQUYyQURGAAoJEEadePR6ryrfyOIP/3Olk10ev81PbGUpBnuCPZkE
wN14R+NDAahhukDMH4BAO0X9Po1AfQyyObP3tncZCIXt/rHfn40oqR/25r486TDV
pbe6lO2alDlvjCc19cmnlOefcJxJAfdTOdy/aOGlQLcaDhGbksD2rSro2AclefDa
irhY6p1cfxRhMvWj753ql7pGJHMlCpU4EFe6HT0JLYAAz6X447KuZbwOvZkp7laB
0gfAHGJXrUCcziTIAbivYUl84TNW7HOjPQmt5/MXrR/aTHycKSUgil6kvJhxM3+a
mhcABVKO5Bjs0tYLsv+bC6r/dOr0ECvOV7PC/0C51m9gA9mGeItff73UIoRxmVw/
1LyZE+zwrOR2yKHih6C4iUzsLJ+hvUOQi1QW6nGnyhKTrMXUEqIyLO+akN4ABVJY
BcX4c1cXxba/4RDFy3og0/ZhaWfpSsFGx4jSAY3AKjQYF7x70CJAwGvSXJmMGMG4
eJO9dmvZc4PHqiC/mdZOSUJA2cqOv5VPJk6bfHj4EbFhe+mWOZjb5SJCkF0X6To1
OEAnb7Zl99dRkiTnNtZKQlycEl+pOt4r8uSh9ndOTK+jlRiCZsnRFZSd8AQfcbL9
Gv+Rjfh3Z4behFUgXJjPc9Fr4fQLwLEA034RSbW3fzhLpBC8WTqAL9PRKvvhoLN1
AXIJAmRzzgISwtLl702Z
=9qf/
-END PGP SIGNATURE-

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

Re: [qubes-devel] [GSoC] Progress report: Anti Evil Maid enhancements

[Rusty Bird]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

Rusty Bird:
> Patrik Hagara:
> > On 06/09/2017 05:22 AM, Rusty Bird wrote:
> > > Rusty Bird:
> > >> In the current WIP version, the keyfile is encrypted before sealing
> > >> and decrypted after unsealing. (Using scrypt - if we trusted the TPM
> > >> to handle the raw keyfile, we could just use SRK password protection
> > >> instead.)
> > > 
> > > Sorry, I have to retract the part that says SRK password protection
> > > for the keyfile is (in theory) an alternative: The SRK password
> > > applies to the unseal operation for the TOTP secret as well, so the
> > > user has to enter it before they know that the computer is in a good
> > > state. But then the attack Patrik pointed out as the motivation for
> > > adding TOTP in the first place would still succeed.
> > 
> > I think using a SRK passphrase is irrelevant in this scenario.
> > 
> > Say the attacker managed to compromise the computer so that it always
> > boots attacker-controlled kernel. User gets prompted for the SRk
> > passphrase and complies, but the TPM will fail to unseal anything since
> > the PCRs wouldn't match -- ie. no correct TOTP code displayed.
> > 
> > The same would be true even if the well-known SKR (ie. no passphrase)
> > was used (which is, to my knowledge, already considered secure paired
> > with removable AEM devices). And it would have better UX -- one less
> > (near-useless, in this case) passphrase to remember/type.
> > 
> > However, it is true that the attacker will have the ability to copy
> > contents of the real AEM stick and on subsequent evil maid attack will
> > be able to unseal both the TOTP seed and encrypted LUKS key file -- and,
> > assuming they also managed to snoop the key file encryption passphrase,
> > will gain access to the encrypted drive.
> 
> Oh, I was originally talking about a theoretical setup where SRK
> sealing _is_ the only "encryption", with nothing host-side like scrypt
> before or afterwards. Where there would be no extra keyfile passphrase
> whatsoever. It's a terrible idea...

Just to really be clear, my error was to think of the SRK passphrase
as a passphrase needed specifically to unseal the keyfile, when in
reality it is a passphrase common to first unsealing the TOTP secret
and then the keyfile.

Eek, I'll stop bumping the thread now.

> But yes, a different theoretical seal-then-encrypt setup would not be
> vulnerable to an evil maid attack per se, and indeed the SRK password
> would be irrelevant (and a nuisance) then, as you say.

Rusty
-BEGIN PGP SIGNATURE-

iQJ8BAEBCgBmBQJZOoucXxSAAC4AKGlzc3Vlci1mcHJAbm90YXRpb25zLm9w
ZW5wZ3AuZmlmdGhob3JzZW1hbi5uZXQ4NEI1OUJDRkM2MkIxMjlGRTFCMDZEMDQ0
NjlENzhGNDdBQUYyQURGAAoJEEadePR6ryrfSB4QAIZQFutZ8TK9o3A704uqOsQm
YkRirmbgWfq6ToN+sRM8wEPWC7VJNvlqYQkFluKddSCpkZ8xqS2nd82lHlvubI9h
qymdVJJvX72oEyaJDx3GDbxNST3FziHRrtxiOHd4CsZH1Xj+bW0VDKuCxA/QzE3i
mlzRxzJRgsntYip2bPX3JNIRc1vxHVCtJuHP4qIqljlvIBfhm5i3yiovCAVLwEJT
j+mtJXIA9GlV6XqKiOVGD3gwDZZtT6J9MzgvtJ5BAVO4p3Lt5GYaQccwJDwk0Uop
BAMgZyD88ydx/je57DZnsdkYJE5V166dFIORkwxDSw0ZXwrVfTQngbKmX4dWD4xQ
lV5n4q1f6hxe4MGLzOzZKxYfDS0HpnLrZTHZIvyydSbwI4Mmn15u2pMFdzeB7cUN
e50/wA2rvzpnA6fv/oCt3WWBOuH0MQ8QmzvnH55XrEVvzuyzQqc/wM+At6I5UxXv
a1ZfDXH+PEfjW8HKYprgvHgW1sK6RYJnt4gICpSBvj2mbSITHIdm1fMAFzwW1LLc
bFrrqH1IzH/Eu+bgpWh2dg3oETRHIcioqbd89aa/lJU28fm5JdY45t4JT39dznag
5SQNw3PhuW0buNFk6lY+slhLaaCpbxI/rO05YjRA1UiJURp49MF+ja9na8FENGjf
5EyUfgj0gKIKaN3Hz0Gj
=npak
-END PGP SIGNATURE-

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

Re: [qubes-devel] [GSoC] Progress report: Anti Evil Maid enhancements

[Rusty Bird]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

Marek Marczykowski-Górecki:
> On Wed, Jun 07, 2017 at 10:45:30PM +0200, Patrik Hagara wrote:
> > On 06/07/2017 09:45 PM, Rusty Bird wrote:
> > > Hi Patrik,
> > > 
> > > Sorry that it took me a while to respond to your first "offical" :)
> > > progress report. This email has some general stuff, but I'll post more
> > > here or on GitHub later this week.
> > > 
> > >> Right now, I would say the first version of my code changes is almost
> > >> finished.
> > > 
> > > I'll summarize part of my mental image of this first version (also for
> > > the benefit of casual readers), please correct me if it's wrong.
> > > 
> > > There are now two new AEM setups: Setup A has TOTP and encrypted
> > > keyfile secrets on the only AEM stick; setup B has TOTP and fallback
> > > text/image secrets on a primary, and the encryted keyfile secret on a
> > > secondary AEM stick.
> > 
> > Yes, that is correct.
> > 
> > 
> > > (Is there any attack where a TOTP secret adds additional security i> 
> > > setup A? If not, it should only be done for setup B, right?)
> > 
> > One possible attack scenario I thought of is for an evil maid attacker
> > to configure the machine to disregard user's AEM boot device and instead
> > boot attacker-controlled kernel. This kernel would then pretend to have
> > successfully unsealed the LUKS key file -- the user has no way of
> > knowing and will thus enter the key file passphrase, which would
> > subsequently get captured for the attacker (along with a copy AEM boot
> > stick contents).
> > 
> > Now the user would have to immediately and completely destroy their
> > computer, even if they are sure nobody has _seen_ them typing the
> > passphrase. I would consider this to be a regression from status quo.

Hell yeah!

Of all the times I've had tunnel vision while trying to keep AEM
attacks and defenses straight, this takes the crown. This and ...

> > With the additional usage of TOTP, this kind of attack will be apparent
> > to the user (wrong TOTP code => do not enter key file passphrase).
> 
> Yes, IMO this case is important - it was exactly the reason why AEM was
> developed in the first place - to somehow authenticate machine to the
> user, before entering the passphrase.
> 
> > The attacker can still, of course, learn the key file passphrase via an
> > observation attack and then seize the AEM stick -- but this is true even
> > for both the "setup B" with two sticks (which would always be carried by
> > the user together, ie. no added complexity to the seizure process) and
> > current "plain" AEM setup.

... the fact that I could have sworn there was a scenario where some
sequence of events involving retroactive access to a recording of a
passphrase being entered made a difference between setup A and B, but
now I can't bring back anything from memory that isn't flawed or
completely unrealistic - I'm taking these as signs that it's very good
to have someone new working on AEM, and with great attention to
detail. Also, that I should make it a habit to write this shit down.

> Yes, this attack is possible because all the user enters is a static
> secret. I was thinking for some time about a scheme where user enters
> also something dynamic - OTP (not necessary TOTP) - either in addition
> to normal passphrase or, instead of. But it's tricky how to do it
> properly.
> One idea is to have LUKS keyfile encrypted with the next OTP (in
> addition to other protections like being sealed to PCR values of TPM).
> And after successful user authentication, prepare it for the next boot
> (since you have access to decrypted disk now, you can access OTP key to
> generate next OTP). In practice probably not just one encrypted keyfile,
> but few of them (like 5) using consecutive OTPs to allow some window if
> you accidentally press a button on OTP token (or a button in mobile
> app).
> This idea have at least few weaknesses:
>  - each boot require some write on AEM media, which means a) it can't be
>read-only, b) in case of flash it will reduce its lifetime (to make
>password really one-time, already used encrypted keyfiles should be
>wiped - probably using shred or sth like this)
>  - if someone copy AEM stick _before_ observing proper successful boot,
>he/she can replay it, because copy of AEM will still have "old" OTP
>valid (a keyfile encrypted with it)
>  - similar to the above - it is not resistant against brute-force
>attack; 6 digit code (or even 8) is not so long, even if you force
>re

Re: [qubes-devel] GSoC Anti Evil Maid improvement project

[Rusty Bird]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

Patrik Hagara:
> On Wed, Mar 29, 2017 at 1:39 PM, Rusty Bird <rustyb...@openmailbox.org> wrote:
> > 1. The TOTP part of the complex scheme. This would be nicely straight-
> >forward, I think.
> 
> Agreed. I even saw an implementation [0] of this (seemingly targeted at
> dracut initramfs) with a fork [1] by the Heads [1] project. The limitations
> mentioned in readme are not applicable to Qubes (except the malicious
> firmware remark, ofc), as Qubes already uses tboot to also measure
> initramfs. If not already a no-op, it should take very little effort to
> make it compatible with Qubes.

oathtool (available as a Fedora package) might fit better into into the
existing code, because tpmtotp needs direct access to the TPM chip.
Which then requires a special case in the (un)sealing scripts to skip or
delay tcsd startup, to invoke the proper sealing/unsealing command, to
transform the PCR configuration syntax in anti-evil-maid.conf from
tpm_(un)sealdata format to tpmtotp format, etc.

> Had I not found the TOTP attestation code, I'd probably move step #1 to
> the end as it requires figuring out the Plymouth UI in addition to the
> actual implementation "guts". However, assuming the existing TOTP code
> can be trivially re-used, I do side with the ordering you proposed.

You wouldn't have to do anything fancy UI wise, "message NN"
(possibly looped in a background subshell) works with and without
plymouth.

Rusty
-BEGIN PGP SIGNATURE-

iQJ8BAEBCgBmBQJY28ppXxSAAC4AKGlzc3Vlci1mcHJAbm90YXRpb25zLm9w
ZW5wZ3AuZmlmdGhob3JzZW1hbi5uZXQ4NEI1OUJDRkM2MkIxMjlGRTFCMDZEMDQ0
NjlENzhGNDdBQUYyQURGAAoJEEadePR6ryrf8lIP/ih1GkE/WIi5KPAowvLp4DCT
X4y30MJ/Qgjd+iofGqaXrHv+QC4+5h0HbG5uS4xYbBK7d+dTY8ff292S9o3C6JrL
KsQlc8MZuAKuN0DipJwRGGWU56SRHBFvAoqGhaZvcwo9qvy5n8Lj7O4i8D29Kwxd
3YfPsoSVTiTk19TwkaVkfZH32drBhno3+9k4aKtrmf4lLJHrYHxiSoletfj/f8IZ
7RcOVXEMv+BImMoGZqTK5ZN2P/9oPatM0dFePJt0YK0SyetBC9L8i2qUamWnafSQ
kNVWdzMlxc3jzQKVBYXdV082OX2CJamth+dwaXxNUXWRvUZ71KCA+FAQO0dsVIkK
w/XS0ioVgjFnPeoiQqZs8Mte3vo9mn7eZBgAMi59UBRZSWHtFQCAICYvxsNSJfc8
QfR161cOr6LeynHlcHt8Jm7lv8EAdzSXiW7JmUeHtjrWrj/SxcO8hyMNHpNqT1oY
NQ91H4gxbTGb37LfRxlN4RxK0I2GdjrDAcgJcf25JqBqx39Fs4demphIlng4m4AF
uRyV+FXB8l8DOVONPtbugYzHbSgTbmBvxrEOLbk5VPYnFVyzOC1AtmnAoPbVRMf6
tjeT5Gzh/v39GRTVo7keMN6qFZBcJu31jb7l2E+2JeG4ytXCp7badiG0drfFxm/c
0JUSbPeZUnmSKir+8Pbq
=q73r
-END PGP SIGNATURE-

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

Re: [qubes-devel] GSoC Anti Evil Maid improvement project

[Rusty Bird]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

Patrik Hagara:
> For such multi-stage attack, it could be be much more effective and
> still perfectly feasible to implant a passive hardware device into
> the target computer that would silently capture and record relevant
> USB traffic. Such device would be invisible to all existing measured
> boot mechanisms and thus undetectable by the user -- the computer would
> successfully authenticate itself, so there would be no apparent reason
> not to insert the secondary USB stick with their LUKS keyfile.

As long as the keyfile is encrypted, and the user has a PS/2 keyboard,
such a USB sniffer wouldn't necessarily be a problem.

> > We could support both schemes and let users choose either or none:
> >
> > - - If secret.luks.encrypted.sealed2 exists on the verification stick:
> >   unseal it, decrypt it, and use it as a keyfile
> > - - Otherwise, if secret.totp.sealed2 exists and we're not in "I don't
> >   have my TOTP device" fallback mode: unseal it and show the code
> > - - Otherwise, unseal and show secret.png.sealed2/secret.txt.sealed2
> > - - If we don't already have a keyfile, and the user inserts a decryption
> >   stick before unplugging the verification stick, unseal
> >   secret.luks.encrypted.sealed2 from there, decrypt it, and use that
> >
> > I don't know if this combination would be too much work for a GSoC
> > project though?
> 
> In case you deem the probability of software-based (but requiring prior
> physical access) multi-stage evil maid attacks much higher than
> hardware-based ones, I could implement both schemes (probably not in the
> two month time-frame of the GSoC, but I could work on it in my free time
> before and/or after GSoC).

Hmm, what do the people on this list think about the TOTP device + two
sticks scheme? Is the small amount of added protection against multi
stage attacks even worth the added complexity?

Rusty
-BEGIN PGP SIGNATURE-

iQJ8BAEBCgBmBQJY2SVKXxSAAC4AKGlzc3Vlci1mcHJAbm90YXRpb25zLm9w
ZW5wZ3AuZmlmdGhob3JzZW1hbi5uZXQ4NEI1OUJDRkM2MkIxMjlGRTFCMDZEMDQ0
NjlENzhGNDdBQUYyQURGAAoJEEadePR6ryrfO+UP/jWUdVMxci36sWNf+1JASc0Y
qh45W/X8mY7U5wew0SNMetD4V8g5ONFTB4mj3LTPpOXzWP7kRd+bdkXwa//fh7I8
FgP6I+b+XGlMnJNY4b9n3CVzorNTDZYxEBub6iHpSz/bgVdB7LzzXUAdD3ei/yaf
c9Y8r6zHkxeQf7kTqWkz6cRYEnKFmuSICEy0XJlpwiCvYyWmCJh3bdflR76d3Iwz
TdeT66VXMdekoyoQvmbMprLTL6IO9UB/ej9jH1Bt+cSsW9jY0zXnn5BT80QZn7Mc
9vQnw0xyC0btzOcp+qPnOOn5YiqVREdP02xaZNNtChN31PDhOSgaD4B0tWEqLNtf
YjwM6qeSXOXg0RgjNJsMpG9U3+/Vp6mw2XXEswoo3eLrdbrpXsVTT671bqqFluN6
6Bs5GtH4RK/mQjpTtx/GSkOZx9FCzUBFizp6MbJjKsO0+154YRGRH9sGsW6qiSok
E3aizJkbsROTIuaBrWkLub5EcZZ3Xr8fhRGQomvfJRkmVe2gXWW7hRIqw9OHZNVz
iEypWXgDS2FglriZIDJSI3XSe4eXXZTNmooqEWbB2xeyCSoqMKk6ExasdhXQKc6+
Dsd3f9vHT7F4I7rhJfDT4UaQncxh5gxTyKK5YlprKmxhGAUnZOczAduBlA4PMjtA
etf2Hw74WFTcZsd2xRIQ
=mIjE
-END PGP SIGNATURE-

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

Re: [qubes-devel] GSoC Anti Evil Maid improvement project

[Rusty Bird]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

Patrik Hagara:
> I'm thinking about applying to the GSoC program and working on
> the Anti Evil Maid shoulder surfing and video surveillance
> resistance project idea.

Awesome!

> However, I've got a question regarding the proposed
> solution which requires implementing both TOTP based
> machine-to-user two factor authentication mechanism and
> support for secondary AEM device containing passphrase
> protected LUKS keyfile (so the user has to carry two
> USB sticks and a TOTP token with them at all times).
> 
> Wouldn't it be sufficiently secure to use only one external
> AEM device containing both the AEM protected boot partition
> and a TPM-sealed LUKS keyfile? This approach would protect
> against keyboard sniffing as no passphrases need entering
> (the LUKS keyfile can optionally be protected by an additional
> passphrase, a TPM SRK passphrase would not add any extra
> security with an external AEM device, and the BIOS boot
> passphrase can still be sniffed by the attacker anyway);
> screen sniffing is also prevented by getting rid of the static
> AEM secret displayed upon successful unsealing, which would
> get replaced by LUKS keyfile unsealing. Such set up would
> successfully and automatically boot the OS from enrypted drive
> only if the TPM PCRs are able to unseal the LUKS keyfile.
> 
> The advantages of this approach compared to the proposed
> solution are: no need of always carrying and protecting three
> separate 2FA devices (AEM boot stick, AEM keyfile stick and a
> TOTP token), no manual verification by the user is necessary,
> no sensitive data knowing which an attacker would be able to
> defeat the AEM trust model are displayed on screen or typed on
> keyboard.
> 
> To defeat the protection offered by this solution, an attacker
> would need to clone or seize the user's AEM stick (and possibly
> also sniff up to three additional passphrases used, namely one
> used for extra encryption of TPM-sealed LUKS keyfile, BIOS boot
> and TPM SRK passphrase).

When the attacker is infecting the user's computer, they could add some
code to copy the sealed encrypted keyfile into the nooks and crannies
(firmware, reserved disk sectors, ...) of that computer. A multi-stage
attack would go like this:

1. Visually capture the boot passwords (or retroactively access CCTV)
2. Infect the computer's boot code (but back up the uninfected version)
3. Wait for the user to connect the AEM stick on the next boot attempt.
   Even if they immediately destroy the stick after noticing
   something's up, they're still screwed:
4. Seize computer, restore sealed encrypted keyfile, restore uninfected
   boot code, replay captured passwords, decrypt disk

So when the computer fails to authenticate itself, not only must the
user have the discipline to stop _using_ the computer. If multi-stage
attacks are part of their threat model, they must also _destroy_ the
computer

- - completely: because who knows where exactly the sealed encrypted
  keyfile has been been copied to
- - quickly: before the attacker can get to it

Whereas, if we put the encrypted keyfile on a separate stick that's only
ever connected _after_ the computer has authenticated itself to the
user, getting rid of that is more realistic. It's just a dirt cheap
little commodity device that doesn't contain any irreplaceable data.

A nice setup would be two microSD cards, in tiny USB adapters[1] if
necessary, on a key chain. We could call them "verification stick" and
"decryption stick", sort of like how people are used to having a
building key and an apartment key?


That said, although the scheme you're proposing wouldn't prevent the
multi-stage attack, it still has _a lot_ of good things going:

- - It improves security and UX, compared to the AEM status quo
- - UX is vastly better than the two sticks + TOTP device scheme
- - No need to trust the TOTP device (probably a smartphone - eew!) to
  authenticate the computer
- - No need for conspicuous TOTP verification


We could support both schemes and let users choose either or none:

- - If secret.luks.encrypted.sealed2 exists on the verification stick:
  unseal it, decrypt it, and use it as a keyfile
- - Otherwise, if secret.totp.sealed2 exists and we're not in "I don't
  have my TOTP device" fallback mode: unseal it and show the code
- - Otherwise, unseal and show secret.png.sealed2/secret.txt.sealed2
- - If we don't already have a keyfile, and the user inserts a decryption
  stick before unplugging the verification stick, unseal
  secret.luks.encrypted.sealed2 from there, decrypt it, and use that

I don't know if this combination would be too much work for a GSoC
project though? 


Rusty


[1] https://www.kingston.com/en/flash/readers/fcr-mrg2 is top notch
-BEGIN PGP SIGNATURE-

iQJ8BAEBCgBmBQJY2AayXxSAAC4AKGlzc3Vlci1mcHJAbm90YXRpb25zLm9w
ZW5wZ3AuZmlmdGhob3JzZW1hbi5uZXQ4NEI1OUJDRkM2MkIxMjlGRTFCMDZEMDQ0

Re: [qubes-devel] usability request

[Rusty Bird]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

Jean-Philippe Ouellet:
> On Wed, Mar 22, 2017 at 8:31 AM, Oleg Artemiev  wrote:
> > Is this OK to provide a pullrequest for adding VM (qube) functionality
> > for kill / shutdown some VM using window color border as a start
> > point?
> >
> >  I'm spending some time to get into qubes manager just to kill or
> > shutdown some qube. This is a regular task in my workflow.
> 
> If you are interested in quickly and easily killing a VM with visible
> windows, then update qubes-core-dom0-linux and add a shortcut in your
> desktop environment for /usr/bin/qvm-xkill. This utility lets you just
> click on a window to kill the corresponding VM.

No, it only causes one of the GUI daemons in dom0 (the one handling that
VM's windows) to exit. But the VM itself keeps running.

Rusty
-BEGIN PGP SIGNATURE-

iQJ8BAEBCgBmBQJY0sKDXxSAAC4AKGlzc3Vlci1mcHJAbm90YXRpb25zLm9w
ZW5wZ3AuZmlmdGhob3JzZW1hbi5uZXQ4NEI1OUJDRkM2MkIxMjlGRTFCMDZEMDQ0
NjlENzhGNDdBQUYyQURGAAoJEEadePR6ryrfOdkQAJWUBCXxdX9BOZWRP2kiZgve
Y5Bgh3Bvdp+nH2MnjvsBafUKnxQqY80BBcw9t/q9LX9Xx4YtCp5E8YZPMguWv0Zu
QuqkD+eXL8et2u7a2P1YIwdYSr0S28/fiFZ3swLgiUfnXYijn0py13plJyMeCkWN
C1HfNqufSeWSNkJ3YMQ1PTZLouKAUU7rys3kC0Tgtj/hzUMSLRDEY3ETjkBsefRS
NBS1YUIuj4yKm2wTUe8JTj3WX8N5LP972A3IngwguDPE1rjBPPlh+EelvdP7ivec
/atOQI5x9MfpUF4g8/8fU+cuEjxM77O5MR99uYWFxwz2j6qpDSMdMaG4Z5C/8eeW
5MgHwruVgAJrj5yovPyzL5ZiN2/rPQhJhOftCn+iZyZ+jWU1d/ztnbTk2MGBW+5I
NQDj2JNshLRQWIEFQYkE1DWswUiD2SegOZp8rSi4QWwLKJ2/yDgfsIZQUT8uj5G2
VLsSjr3s+beHpB31u2uqbnCHNGCLEPUAdMjfq7CTsPw7bXc5iovIXpymNRUqigCe
/eaYVVvYhjC+wJ35WiLQaOzlKYk+3xkPF5c6bPgbX4IUY7i7fMOMppZaGle8mqBX
eGDV0upe0yBqsWyB7x78YiGuGrUHeu8hli5NlScuCF5Z03QdZ/8ZYhdQKAmlmnyW
jBRbCWQ3yo3pHOG3PTpV
=1+S3
-END PGP SIGNATURE-

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

[qubes-devel] Re: [qubes-users] Back up running VMs on btrfs

[Rusty Bird]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

Chris Laprise:
> On 02/21/2017 07:43 AM, Rusty Bird wrote:
> > Hi Chris!
> > 
> > > On 02/20/2017 08:28 AM, Rusty Bird wrote:
> > > > A small qvm-backup wrapper script that handles running VMs by chrooting
> > > > into a temporary dom0 filesystem snapshot. The backed up data is the
> > > > same as if those VMs had just been killed, which seems to work fine for
> > > > the usual journaling/copy-on-write VM filesystems.
> > > > 
> > > > https://github.com/rustybird/qubes-stuff/blob/master/dom0/bin/qvm-backup-snap
> > > IIRC, the best practice for backing up is to use a snapshot as the source.
> > > 
> > > I was thinking that a simple ability to point qvm-backup to a snapshot 
> > > path
> > > would be optimum for backup flexibility.
> > I misremembered that as involving a fair amount of refactoring.
> > Looking into it again right now...
> 
> There is the issue of handling multiple pools or mountpoints (if they are
> configured), but as a personal modification to allow backing-up while
> running VMs I'm guessing it should be pretty easy. As long as everything is
> on one fs.

https://github.com/rustybird/qubes-core-admin/compare/snapdir implements
a new qvm-backup option:

  --snapdir=SNAPDIR Specify a filesystem snapshot directory to back up
from. VMs are allowed to run while being backed up and
the destination VM is not automatically excluded.

But I don't know if it makes a lot of sense to submit this patch as a
pull request. It would have to be reworked for core3-devel anyway.

CCing qubes-devel

Rusty
-BEGIN PGP SIGNATURE-

iQJ8BAEBCgBmBQJYrIU0XxSAAC4AKGlzc3Vlci1mcHJAbm90YXRpb25zLm9w
ZW5wZ3AuZmlmdGhob3JzZW1hbi5uZXQ4NEI1OUJDRkM2MkIxMjlGRTFCMDZEMDQ0
NjlENzhGNDdBQUYyQURGAAoJEEadePR6ryrf4nkP/istS24pvQAAzfLAusMymUip
M6idbBoye4k5adtNHyjFvsYrGRCxxOFFNF05U99cMUYITVf6isi5Rmz3fsLpz3Eu
CUztp3WBnTUNsQTQJpxwgwgqjmoEQf8Dkh0Aude2K3Mz2ARBR1mawfpzegVg2OfX
CIotNrpVRRqOJHBQGup0o43EhftNnUXfkdobrG9j9QPYWMoLuKJF9EMEW/QQcmNu
CazD6/op3JiFoGUHH2Kg1KocoPxAVMD9pwJJNZUVsfkHtnRjxEfN0oTpkhvONHYj
cB3GS/hF5q7Rck7wR8nehCzLacJ6iC3O14Ed6Y5T3e7OvBU/17hC73y+bS+tEHWH
UBfpmbL58JumGWUysurai29XQAIpJr5BNUtYtXsBoWBcOV3Gfe0xAOkTPfu+8xJO
df9elpBkIurvqmjSrGxQO5kfe+GUVbC9RgDWa4cZ33ajyr76Bg8lY9b7yYabmQ8t
m+g/FEx9O2KnmAo12mYrE05d239auLWmCbCtT9rRZJ1WxVjggpqQXhduBwo90I7C
IUs78pxHo3pf2bI64QSEa3y5K5c+C7PaKZZfzFV+WnDV59kMsVrGrC1XeIxHQ7XT
cS6v6WmYYC7DSVN2J71vhTtptZl0ojWXdOTSuA3B8cgWhXJ9+o0cAkvJynL45neP
ci5Yr+rxubeZewJ7dWVM
=yKMm
-END PGP SIGNATURE-

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

Re: [qubes-devel] Heads firmware talk at CCC

[Rusty Bird]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

Trammell Hudson:
> The one drawback to the rd.luks.key approach is that only a single key
> can be passed in.

You can also use "[rd.]luks.key=LUKSUUID=KEYFILE", no idea if that works
any better in practise...

Rusty
-BEGIN PGP SIGNATURE-

iQJ8BAEBCgBmBQJYZoXVXxSAAC4AKGlzc3Vlci1mcHJAbm90YXRpb25zLm9w
ZW5wZ3AuZmlmdGhob3JzZW1hbi5uZXQ4NEI1OUJDRkM2MkIxMjlGRTFCMDZEMDQ0
NjlENzhGNDdBQUYyQURGAAoJEEadePR6ryrfFZ0P/3muJXRvRR9gfUF/AJV2yM9y
Iu/JjyHf5OzNcTHHAY4EbFZMtBmlugPZP+1PDds0X6ajd7RYxrFCHvkcMuDKXj1K
+oDtsbud9SD7P4Y+5cm3V/oKkmaJFI5CzBbtDwZ9REnEFsmr1XTwlCXLAxSY/IqH
RmMa5Dm4ytmbZay0iZUk/Ak/GXqDXSfqE6eVtifmgzfwhdb4bWVQ8ewUMRck3MDp
GJcAR7CPPsGPceAyF5O7sRlZ8gmoafLbmFgKExmyqfZwuyKQm3HE8AEaCKoS4sLZ
HDDIBmP+ixXx4gR4pv5PUQrvhhG5sjUOXpzCY0WtbpU4g7q8iOZGVHX7zmjXqXkI
ISAv8lH/LSNhvUQRxOkYWfbtAr19Q5kXJUJIwqQFdLheSepptKwL+M76l6oFqj4W
v0uL4wbv5zovbNwAa1qqSNFFMg+/fh1fHb0fDgVHydesoa5F8Ln8ZaWAk1qhiH1U
PjrZKYV48vTYE2BVClbNIsGkFog3slNkeGajZAVqm2taMQNMhI0lSwSeMjzAk2As
GOnlBZ5e/NFj0jbmtzMQrNhylYFSPclJaJxXm+G3eVr4OZc55AZbGxE1AgNGzXQH
bKT2q7UXofuwiSmT1hQHT8lrmdpdnlWqUAdXd38/sAVYkIzyL3CoDCLFJHppzb7/
BY2L3xxprRa6VSn4MFbQ
=HFQ1
-END PGP SIGNATURE-

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

Re: [qubes-devel] Heads firmware talk at CCC

[Rusty Bird]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

Rusty Bird:
> Trammell Hudson:
> > On Tuesday I presented my work on the Heads firmware at 33C3 and
> > gave Qubes OS (and Joanna's 32C3 tallk) a shout-out.  You can watch
> > the video, titled "Bootstrapping a slightly more secure laptop":
> 
> This looks really nice, I hope to finally be able to try it soonish.
> 
> With Qubes already moving towards open firmware (which probably means
> coreboot in the foreseeable future?), Heads seems like it could be a
> kind of natural successor to AEM and get rid of all the tboot/SINIT
> related headaches.
> 
> Has there been any progress in upstreaming the hypervisor patch, now
> that you have a rock solid use case?
> 
> > I'd really like to figure
> > out how to pass the secret key from the Heads bootloader to Qubes'
> > initrd in a supported fashion.
> 
> If I understand it right, [rd.]luks.key= isn't working as it should?
> I've played around with that a tiny bit and systemd-cryptsetup-generator
> was indeed behaving weirdly, some "out of memory" nonsense.

Which might be fixed by
https://github.com/systemd/systemd/commit/c802a7306bdc3e82378a87acd9402bbabe9f6b28

Rusty
-BEGIN PGP SIGNATURE-

iQJ8BAEBCgBmBQJYZX4oXxSAAC4AKGlzc3Vlci1mcHJAbm90YXRpb25zLm9w
ZW5wZ3AuZmlmdGhob3JzZW1hbi5uZXQ4NEI1OUJDRkM2MkIxMjlGRTFCMDZEMDQ0
NjlENzhGNDdBQUYyQURGAAoJEEadePR6ryrfbZYQAIn/8xXRR6hR+y59wtmJ1rkW
YopRLe83XpyDp3+LJ1qsMygy0EsmKCk964ccUlMrm8VyrDuHV40qpvRMqLew/jX9
H9h4wqoVgNcp6rtfzWMzEOfRCLsid8w6emcqOn9fZFaM7bISWNFXwZFmt3j14RWM
+py9oVLTRSjKYIfOX2VcSFZykQjIGl/fXHYPQskLEfL6Y0x2ngWM/ODpMv5Yd5kI
VXCUy6CgCoyo7jl7AD59Bcozxvm4+ne9g2NiL6nzg/t0w6l8JwieetVSzEsN0mvY
XvoaLBOPyXZNXyGIarJjLyAjEO85KEUz04bslfzF6gJ6O125dhaEGj+rbpi3THAo
T6b4kbr9DZRSZ5ggjVvLuHykz9Am4YyAoAYHv/2DkAPAjNYoT3PVc52buUoCnowp
ocKPqJLQ6SLvLQFjza8qEo+5Ka2Tgy4mRDJBKsjFfS2cCG1eeuH9+aWJtZ4Gkral
yX31ry1e0YSk+DLTNlo2mldjMU1XQj6fauSaWcDh4Gi1CtVPEri/OphTco+lkTfC
Zye3ZSvsInmSblBHCVRCSTc1hoAIS/Qf8hWBdg4XbJEkdfbLIZukh10vicuz8UKU
7bvJQrQGhDYXFvJgLN0zAZkdrwHismbejl0cxr74tDW8s8AUTCmc9TUnTFTmDn0D
AV9b17WxQP3Yxt7wQa1Q
=AlFX
-END PGP SIGNATURE-

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

Re: [qubes-devel] Re: qubes-updates-cache, a Squid-based package update cache

[Rusty Bird]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

Hi Iestyn,

> I tried retrieving the journal for qubes-updates-cache but it only
> had one line that described the timeframe for the journal.

Can you paste the output of "systemctl status qubes-updates-cache"?

Rusty
-BEGIN PGP SIGNATURE-

iQJ8BAEBCgBmBQJXsHFdXxSAAC4AKGlzc3Vlci1mcHJAbm90YXRpb25zLm9w
ZW5wZ3AuZmlmdGhob3JzZW1hbi5uZXQ4NEI1OUJDRkM2MkIxMjlGRTFCMDZEMDQ0
NjlENzhGNDdBQUYyQURGAAoJEEadePR6ryrfnlUP/3K9WJY7iRcuxos+ub7DD0+y
xot5Z0HMQYM+j8tvhni+yIPK3zaiqEoh0S1LWoRbDJToCunojFmcYG7mgniWy4wq
+Z75ZTjfse203P3mF2/XaXv/QDWmkgMSN5Jc4Y68sNod17GcoU3FrYJ1UcReHLrj
YsglL6+0la+xo/KWkLTXa+7jVF3RQ+r1g+DT7huBrbsD6PYQTjoVjEM6He1m45ty
e4oE6UDoLr4gQUyeO4ib4+yVEMdEa8Ik6i3qV+uADInypl6Ub9FMBP9Lh393REaZ
cXxPxPM6x9izVVCDqkiuIHcL2zYDFP8kxrY7mWSjwTiGYvLDTDxYjMZ56GQs93yP
36Kumdwy1y5u54I0+ZuKMWOW/voLHQ/sPrwqQZ/8FvQ6CBrK4rzOuaquaxPTFbay
QknivCOcUVm3zbkXR+8Xoh3Gg/HcnVjDC08mqaukYn4kCU2EATWmruEYT0Ye3oxr
JYgrTO9pbNSytGPQvBS2kO6JMc1uYx+++kb6uN2tz0fdS+VizyyLuYvhdtqT44io
QZ+GdMt9ROj3poaMiI+q5mkSo9UZQiuofbtZeQUYK0ZtYzEOsny63bVigZLaEYlV
eSwc45NMmGM8aepRknSW5hrH9I3kg/Iyxt7Ks8dkbe1p5zSxH4b3jd9A4zT970Ui
94Jx/5bSKMixRqtfJLoO
=nVzK
-END PGP SIGNATURE-

-- 
You received this message because you are subscribed to the Google Groups 
"qubes-devel" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to qubes-devel+unsubscr...@googlegroups.com.
To post to this group, send email to qubes-devel@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/qubes-devel/0fc49fbf-995b-6a9d-50e8-6ce6a5e6b7c0%40openmailbox.org.
For more options, visit https://groups.google.com/d/optout.

Re: [qubes-devel] debugging systemd ordering cycle

[Rusty Bird]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

Hi Patrick,

> I would appreciate suggestions on debugging systemd ordering [and
> also dependency] cycles.

If the cycle is relatively short, you could try opening a couple of
terminal windows and running "systemctl show" commands on each of the
mentioned units, to look at interesting property values with drop-ins
and defaults included:

systemctl show -p After,Before,Wants,Requires,RequiresOverridable \
   -p Requisite,RequisiteOverridable,BindsTo,PartOf   \
   -p Conflicts,DefaultDependencies  |
grep --color=never =.

Rusty
-BEGIN PGP SIGNATURE-

iQJ8BAEBCgBmBQJXl3bOXxSAAC4AKGlzc3Vlci1mcHJAbm90YXRpb25zLm9w
ZW5wZ3AuZmlmdGhob3JzZW1hbi5uZXQ4NEI1OUJDRkM2MkIxMjlGRTFCMDZEMDQ0
NjlENzhGNDdBQUYyQURGAAoJEEadePR6ryrfQEIQAJB+i90kiMm4nn11VUS73EJw
bVVsvSOf3BdFaeJMnnT2+1suEtalN8Ounm++4dwHN0/G2OLkps4xVzIdgG1MFknH
+a6jvd+dF9LFcKoL1Rxp7xFmQsvAJ1VTz8LSoDThEtaqVlSsaVnXicFFxWfpCn8d
pd7nWmAArFUszea+30uL6JA781kTc0vBBYNyPx4RQwAAtbHHbIi1cC4ra/8m0bGD
SbTb+DDziFtpAtJk+X8cxnVb8PXj+I5q+aMGvsRN4zZ3YbkkamIVlLi35on8rRxh
29RqUWeJphnCPaHzBFLiCciKUGtiIy5hiVBp4uxYmDfesti8QB3X3jTyVE7H3FDC
NnCUYPAHJU69Bh+QUxx5heA1U/N4dNzhX25tL9jI6YhK1MVbqHKRLTDH+bs9eg6k
G5VMAdVFKAijoY+c40SVrNorWUj7UPNXzQMV8XoUeNCoRAgZydc7w2q/pDoElleJ
x1r8zkCqRqVnjnS2tcLGx65tM9kBr1BdsiiMtgr1uUYnHmyoNEjteDgFJ32XvQXJ
vB/l/xmP6c12CUfQLBFzcwmn4HVwpQN6FJhOLeXAI/LU9xfLiItWQTiU6TBovIvO
o+dVPm+/aw7jXhuaZU3JMaeC+iQJO4nRKQIxkeSt/nouI6GMz8heS1BAWXDHFlpu
FRso3UXifvAPdVkWPIR9
=+j4J
-END PGP SIGNATURE-

-- 
You received this message because you are subscribed to the Google Groups 
"qubes-devel" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to qubes-devel+unsubscr...@googlegroups.com.
To post to this group, send email to qubes-devel@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/qubes-devel/c851fda3-9412-e73b-b874-df493e4a881d%40openmailbox.org.
For more options, visit https://groups.google.com/d/optout.