19/06/14 18:33, intrigeri wrote: > anonym wrote (19 Jun 2014 14:11:48 GMT) : >>> commit b7f5054339ead7257eb49b973f24679534b3cf9f > >> Just a comment: This will not work with Tails <1.1 fed to --old-iso >> since the test suite has been updated for Wheezy... > > Right. I was aware of it, but I wanted to start with adding a check > (untested yet) that ensures we don't see regressions on that front in > the future. Anyway, that's merely an additional test, that should > (hopefully) not break anything else. Good enough?
Yes, I just wanted to make that clear. >> This seems safer and quite simple, even though the duplication (syslinux >> both inside the squashfs and on the image's root fs) is a bit unfortunate. > >> In the future we could avoid that and use the in-squashfs syslinux >> binary without root privileges by employing stuff like fuseiso (in >> Debian), squashfuse [0] (not in Debian, but see [1]), and fakechroot (in >> Debian) instead of a real chroot for running the syslinux binary. > >> Beyond eliminating the duplication of syslinux, we'd get the "mechanism >> to run post-upgrade scripts" you mention in comment 4 of #7345 [2], >> which may come in handy in the future. > > It certainly would be interesting to look deeper into this some day. https://labs.riseup.net/code/issues/7422 >>> I'll also have to test all other installation and upgrade scenarios, >>> to make sure I didn't break anything else. > >> If you would enumerate these I can perhaps help a bit on Sunday, >> depending on how much other review work there's for me then. > > I want to test clone'n'upgrade, clone'n'install, and a "real" IUK > upgrade. All these from 1.1~betaN and 1.0.1 + the new liveusb-creator. > Help is warmly welcome. I'll see what I can do on Sunday. > I'd like to also add to the design document a minimal discussion of > the security impact of these changes: basically, anyone who can feed > an arbitrary IUK can run arbitrary code as the tails-install-iuk user > (we don't care, the same adversary can plant a persistent rootkit > anyway, but then it made me think and file #7410, that I'd like to fix > at the same time); and anyone who can feed an arbitrary ISO into > liveusb-creator can run arbitrary code as the user running > liveusb-creator (no big deal either). In both cases, no big deal, but > I'd like to document *why* it's no big deal, so that it's easier for > others to review my reasoning. Indeed, please do this. >> I'm confused. Isn't the purpose of this bugfix branch to allow the 1.0.1 >> -> 1.1 upgrade using "Upgrade from ISO" (even if it requires some >> additional steps *this* time)? If so I definitely think we should >> instruct users to upgrade liveusb-creator. Or do you just want to have a >> fix for when this happens next time? > > My intent was to fix for real the underlying, deeper problem that > causes #7345. I wanted to investigate the feasability of this > solution. Now it seems to be proven, so we can actually discuss > whether we want to suggest anyone to use this solution *this* time, or > just merge, add to known issues in the 1.1 release notes, and be happy > that the problem won't show up anymore. Cc'ing sajolida to get > his opinion. I see. Still, the instruction's won't be too complex, right? It'll be something like: 1. Boot Tails 1.0.1 2. Enable admin password 3. Start a root shell 4. apt-get update && apt-get install liveusb-creator syslinux 5. Proceed normally Right? If we choose to not document this path we still have to make it *very* clear that "upgrade from ISO" is not supported, probably very early on, not just as a footnote in the known issues section. Cheers! _______________________________________________ Tails-dev mailing list [email protected] https://mailman.boum.org/listinfo/tails-dev To unsubscribe from this list, send an empty email to [email protected].
