On 10/06/2015 15:20, aab3r@??? wrote:
> Ok, i think i got it. I did a new freepto install, enabled persistence
> and rebooted. I put on hold fuse and ntfs-3g, and then i ran apt-get
> update and apt-get dist-upgrade. This time, everything went fine.
wow, great bug hunting. we should maybe hold them automatically.
> 1) If upgrading initramfs-tool should not be done, i guess those two
> packages should be "holded" in the freepto image.
Unfortunately it's not that simple. Many packages have a "hook" so that
updating them will result in an updated initramfs. This is correct, but
the initramfs should not change in freepto. So we should hold all of
them, but there seems to be no automated way of doing it.
> 2) Both packages have newer versions in wheezy and are marked
> "Security", so i guess is important to update them...
more generally, in freepto what's in kernel-space (kernel, modules, etc)
cannot be updated, which surely is a security issue we need to handle.
> The problem is kind of solved now, but i'd like to hear your thoughts
> about the concerns. And please let me know if you need me to make any
> other test.
Our consideration is that kernel-space serious security bugs are rare,
or not very impacting for the user in our threat model.
When we do a new _build_ of freepto, we of course get the latest debian
kernel. So if there's the real need to update to a newer kernel, we can
release a new build.
The migration path from a freepto installation to another one is at the
moment still not easy, not very documented, and surely not automated.
That's why we are writing "newborn"[1]. There's nothing ready yet, but
it doesn't seem very difficult and we have a decent design, so we hope
to be quick!
Thanks for the bug report and the good questions!
[1]
https://lists.autistici.org/thread/20150601.152207.a36fc15e.en.html#i20150601.152207.a36fc15e
--
boyska
gpg --recv-keys 0x58289ca9
