20/11/12 16:02, Lukasz Dobrogowski wrote: > Hello there, > > today I stumbled upon > https://tails.boum.org/todo/remember_installed_packages/ and decided I'd > like to try my hand at the problem.
Awesome! :) > So, according to the current todo page, there are proposed 2 approaches > to the persistent packages problem: > > 1. an applet asking about installation of cached apt packages upon > login, probably by looking at stored *.deb files. > 2. writing down the autoinstall package list in a configuration file > alike to live-persistence.conf, or even in it itself, and install them > upon booting without user interaction. > > I have to say that the 2nd idea appeals to me much more, since the goal > of server edition is to make the system bootable with as little > interaction as possible. Approach 1 (well, some kind of GUI approach) and 2 are not mutually exclusive. For instance, the applet described in 1 could generate the list described in 2. That would actually fit nicely with how we're currently thinking about implementing Tails Server Edition: if you want to re-configure it, you boot it in a graphical mode with X starting + GUIs (like 1) that will save the configurations; if you want to boot it in server mode, it won't start X, it will just set up services defined in existing configurations (like 2). Another thing to think about for 2 is whether the list would contain only the "leaf" packages, or if it also would have to list all dependencies. > To be honest, I can't think of many use cases > that would require disabling different packages you installed on your > persistent volume every boot. I think the question is more about making it easy (= user-friendly) to manipulate the list of packages to install in the first place. And for that I believe a GUI is necessary. > As I see it, that's the only flexibility lost by 2nd solution compared > to the 1st one. Flexibility, perhaps, but what about usability? A GUI wins for people uncomfortable with adding arcane package names into a file, and these are part of Tails target audience. > Also, there is this point: "The security implications of this whole idea > needs to be researched before diving in the code.". I am afraid I am > unable to research this to deeply... since the cached APT packages are > hand picked by the user, security will depend on these packages and > security of the persistent volume where the *.deb are going to be > stored. Am I missing something here? Perhaps not... :) I think we need to make you conclusion above part of the design and security model, i.e. it's up to which packages the user installs. Us investigating every package and black-list ones that e.g. screws up the firewall isn't sustainable. We would of course document some general guidelines about which type of packages that could be risky to install. > As for the sources of packages (persistence cache / web mirrors) the > only sensible way is IMHO to use the cached versions, since we can't > assume internet connection. That depends on when the packages are to be installed. But I tend to agree that it'd be best if this happened before GNOME etc. starts, and then you're correct about us being able to assume an Internet connection. > To make sure the packages are updated, a > mechanism to check for updates once internet connection is available > could be put in place. (something similar to the one launching the Tor > Browser Bundle only after WLAN connection is successful) You mean something like running `apt-get upgrade $LIST_OF_APPS`? Sounds ok. The upgrade list presented by apt-get should be parsed and displayed in some GUI, though. Or maybe existing apt upgrading GUIs can be used? Can they be limited to only deal with a subset of installed packages? > I was warned that I should ask for opinion before delving into code, so: > what do you think? Let's wait for some more input. In general I think you need to think more about GUIs so this feature in the end can benefit non-experts. However, implementing just 2 first (hence only making this available to advanced users) and waiting with the GUI + upgrade support would be a good and natural first step. But there's still some thinking left to be done on that level too. Cheers! _______________________________________________ tails-dev mailing list [email protected] https://mailman.boum.org/listinfo/tails-dev
