<wpwrak>
now, in the past she complained that the cloud service (some apple thingy) would constantly remind her to make backups. her reaction: "i don't know how i would back you up. do it yourself."
<wpwrak>
well, seems that she may have two more wishes left (-:C
<eintopf>
wpwrak: hi
<eintopf>
can I talk "under the hood" for we should not hide a discussion about something?
<eintopf>
I simple used it right now, doesn't matter now :)
<wpwrak>
i might be able to answer that, if i had understood what you actually asked ;-)
jekhor has joined #qi-hardware
<eintopf>
wpwrak: kann ich schreiben "we should not talk about this under the hood" - Wir sollten das nicht heimlich besprechen?
<eintopf>
google translate said something about "Motorhaube" :-)
jekhor_ has quit [Ping timeout: 250 seconds]
<wpwrak>
"we should talk about this openly" ?
<wpwrak>
so, someone asking silly wpan questions in private ? :)
<wpwrak>
then you could just suggest the list or a channel, since there's usually no implied secrecy anyway
<DocScrutinizer05>
randomly picked quote >>Any library that is not included in the runtime the developer picked must be included in the app itself. This is similar how apps on Android declare one very specific Android version they are developed against. This greatly simplifies application installation, as there's no dependency hell: each app pulls in one runtime<<
<DocScrutinizer05>
poettering at his best
<DocScrutinizer05>
"the systemd cabal" - suckers
<DocScrutinizer05>
oooh btw btrfs will be the only fs allowed for rootfs
<whitequark>
it has some interesting and sane ideas
<whitequark>
but the proposal as a whole seems misguided at best
<DocScrutinizer05>
pretty much, yes
<DocScrutinizer05>
seems to be the proof that he's on crack, to me
<DocScrutinizer05>
particularly sneaky: his sidenote introduction of Trusted Computing[TM]
<whitequark>
these trust root thingies are OK when you control them
<whitequark>
in fact, it's pretty much required to keep a system secure when it's written mostly in C
<DocScrutinizer05>
you cannot control them, this would defeat/break the *concept* and render whole TC as a broken pile of stinking... problems
<whitequark>
uh, what?
<whitequark>
of course I can
<whitequark>
I can control the UEFI on my laptop. it requires some BIOS gyrations, but in fact this is a *required* feature for laptop UEFI
<whitequark>
i.e. you, as a user, MUST be able to replace all existing keys with just your own
<DocScrutinizer05>
the "chain of trust" needs to be unbroken from repo to app. No way end user can hold the keys
<whitequark>
uh, no, not how it works
<whitequark>
or rather there are several chains of trust
<DocScrutinizer05>
of course, exactly how it works
<whitequark>
one chain of trust certifies the boot process, another the app
<whitequark>
I was talking about the first one just now
<DocScrutinizer05>
haha
<whitequark>
the latter one, you ALREADY have on your debian system
<DocScrutinizer05>
exactly
<DocScrutinizer05>
but what poettering suggests is not that
<whitequark>
>In fact we want a fully trustable OS, with images that can be verified by a full trust chain from the firmware (EFI SecureBoot!), through the boot loader, through the kernel, and initrd.
<DocScrutinizer05>
when you can have an "untrusted" bootloader or kernel, the whole trust in apps is for the arse
<whitequark>
no, it's not, it just has different goals
<whitequark>
you won't be able to deploy DRM
<whitequark>
but you WILL be able to deter for example malware writers with rootkits
<DocScrutinizer05>
errrr
<DocScrutinizer05>
that's what SElinux is meant for
<DocScrutinizer05>
and MD5sums
<whitequark>
LOL
<whitequark>
md5sums.
<whitequark>
I can forge an md5sum with a piece of paper and a pen (almost)
<whitequark>
but more seriously
<DocScrutinizer05>
I'm pretty sure Poettering is exactly 4 months late
<DocScrutinizer05>
err 5
<larsc>
is he pregnant?
<DocScrutinizer05>
well, when it results in Linus and other guys with their brains still fully working are now completely rejecting poettering crap, it may have been a good thing in the end
<DocScrutinizer05>
pregnant? no, I think this would have made a fine blogpost for April 1st
<whitequark>
DocScrutinizer05: ok, I don't really have time to dissect Poettering crap
<whitequark>
but having a trust root on a system is a very good idea
<whitequark>
and any modern system MUST have one
jekhor_ has joined #qi-hardware
<DocScrutinizer05>
my systems work great without
<whitequark>
the plural of anecdote is not data, etc
<whitequark>
your system is insecure as shit
<whitequark>
Linux is
<whitequark>
the Linux userspace is even more
<whitequark>
right now, if you have a rootkit on your system, you will probably never know
<larsc>
well at least this will provide for some popcorn
wej has quit [Ping timeout: 250 seconds]
<DocScrutinizer05>
((you will probably never know)) well, just like you, or anybody using this TC nonsense
<DocScrutinizer05>
once you have it on your system, the idea _is_ that it's not noticeable anymore
<DocScrutinizer05>
the question however is how it got there. For that the chain of trust may help, but only when you accept that somebody else you trust is signing the kernel resp rootkit-space
<DocScrutinizer05>
otherwise there's not a single benefit from signing stuff over other methods to make sure the rootkit doesn't infest your system
<DocScrutinizer05>
I rather rely on not getting any malware infested kernel rather than testing a signature during boottime
<whitequark>
DocScrutinizer05: uh, incorrect.
<whitequark>
if you don't have the key in cleartext, even if your kernel got owned, after reboot you are either 1) back to clean system 2) back to a system which doesn't boot
<whitequark>
the issue is not getting a malware infested kernel
<whitequark>
the issue is a rootkit modifying your boot chain via a remote and a local vuln
<whitequark>
remote to get on your system, local to get root. linux has hundreds of local root vulns, it's a complete abundance
<whitequark>
and remote ones are relatively plenty too, especially if you run some shit userspace
wolfspraul has quit [Quit: leaving]
wej has joined #qi-hardware
<DocScrutinizer05>
granted. But the stuff poettering wants to implement is much closer to TC than to your usecase, for all I understand from skimming over that blogpost
<DocScrutinizer05>
and that's only one of the idiocies in that proposal. btrfs as mandatory component of the architecture is another one
<whitequark>
DocScrutinizer05: I agree that poettering proposal is silly in general.
<whitequark>
I just want to say that I am very unsatisfied with the current state of Linux too, for some reasons that are similar to his
valhalla_ has joined #qi-hardware
<DocScrutinizer05>
ok, we easily can agree on this :-)
valhalla has quit [Ping timeout: 260 seconds]
<whitequark>
for once :D
* whitequark
goes back to designing a quadruple mass analyzer power supply
<whitequark>
12kV, 3MHz sine, 100W or so
rz2k has quit [Read error: Connection reset by peer]