Stories
Slash Boxes
Comments

SoylentNews is people

posted by LaminatorX on Monday September 15 2014, @11:59AM   Printer-friendly
from the Trustix dept.

One thing I have yet to see discussed about systemd and the "unified package manager" proposed by Poettering is the stated objective [among others] of tivoisation of linux:

We want our images to be trustable (i.e. signed). 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. Cryptographically secure verification of the code we execute is relevant on the desktop (like ChromeOS does), but also for apps, for embedded devices and even on servers (in a post-Snowden world, in particular).

Am I the only one who is scared of this "tivoisation" by design? If this ever makes it to arm devices, say goodbye to DD-WRT, OpenWRT, Tomato, etc. And that will be just the beginning. Be ready for all your devices becoming appliances, non-customizable and to be thrown out as soon as they become obsolete by design. Being allowed to only run signed code will probably be good for redhat, but will it be good for the user?

Strange that a few years ago "trusted computing" was stopped, and now it seems almost inevitable even in Linux.

This discussion has been archived. No new comments can be posted.
Display Options Threshold/Breakthrough Mark All as Read Mark All as Unread
The Fine Print: The following comments are owned by whoever posted them. We are not responsible for them in any way.
  • (Score: 0) by Anonymous Coward on Monday September 15 2014, @12:10PM

    by Anonymous Coward on Monday September 15 2014, @12:10PM (#93382)

    Just a transparent attempt by Poettering to make sure that even if you don't run Red Hat, you still have to run Red Hat.

  • (Score: 2, Interesting) by datapharmer on Monday September 15 2014, @12:19PM

    by datapharmer (2702) on Monday September 15 2014, @12:19PM (#93386)

    They've got this on chromeOS. As long as they keep the screw there that I can remove to write to the firmware I really could care less. Sure, it is a bit of a hassle, but honestly updating firmware SHOULD be a hassle. The flash from windows is scarily easy to do which makes one wonder how many UEFI/BIOS exploits are in the wild that we simply don't know about.

    Secure boot is a terrible implementation of a good idea, but as long as there is a way to turn it off without breaking things I could really care less.

    • (Score: 0) by Anonymous Coward on Monday September 15 2014, @01:01PM

      by Anonymous Coward on Monday September 15 2014, @01:01PM (#93411)

      I could really care less

      So you mean it's not entirely uninteresting?

    • (Score: 0) by Anonymous Coward on Monday September 15 2014, @01:44PM

      by Anonymous Coward on Monday September 15 2014, @01:44PM (#93427)

      [...] I could really care less.

      If you could really care less, please do. DO care less!
      On the other hand, if you couldn't care less, I would agree with you.

  • (Score: 5, Insightful) by dublet on Monday September 15 2014, @12:21PM

    by dublet (2994) on Monday September 15 2014, @12:21PM (#93387)

    "We want our images to be trustable (i.e. signed)."

    Really? I don't.

    "In fact we want a fully trustable OS"

    I want my OS to be open source, secure, reliable, quick, easy to manage.

    "with images that can be verified by a full trust chain from the firmware (EFI SecureBoot!), through the boot loader"

    I want my boot loader to load whatever I tell it to. And how do you know you can trust "SecureBoot"? How many NSA backdoors does that have?

    "through the kernel"

    I want my kernel to do kernel things only, like memory management, loading drivers, whereever they are from. I don't want to rely on a third party to approve any drivers, if I did, I'd run a Microsoft platform everywhere. And ironically, their driver signing system is largely ignored by both end users and companies.

    "and initrd."

    I want initrd to load the scripts it needs to start, no more, no less.

    " Cryptographically secure verification of the code we execute is relevant on the desktop (like ChromeOS does)"

    Really? Isn't that a bit overboard? I mean if you go the whole trust way, you can verify your source code, but how can you trust your compiler [bell-labs.com]?

    " but also for apps, for embedded devices and even on servers (in a post-Snowden world, in particular)."

    Oh come on. Security comes from many things but not from trust. In fact, not trusting anything, including any signings and verifications is more trustworthy than those signings and verifications. For all you know, they've been faked too.

    • (Score: 3, Insightful) by E_NOENT on Monday September 15 2014, @12:50PM

      by E_NOENT (630) on Monday September 15 2014, @12:50PM (#93407) Journal

      Oh come on. Security comes from many things but not from trust. In fact, not trusting anything, including any signings and verifications is more trustworthy than those signings and verifications. For all you know, they've been faked too.

      Agree, 100%.

      A corollary to this point is that simple, elegant systems tend to be more easily audited (and potentially more secure) than byzantine ones. So what if $TECHNOLOGY is Free/Open, if nobody can understand its complicated interdependencies?

      --
      I'm not in the business... I *am* the business.
      • (Score: 0) by Anonymous Coward on Monday September 15 2014, @01:20PM

        by Anonymous Coward on Monday September 15 2014, @01:20PM (#93418)

        Yeah, the term "Trusted Computing" brings up the same warning bells as when hearing someone referenced with a nickname like "Honest (insertrandomname)" which is generally applied to some used car dealer, politician or other random conman.

        Does that sort of thing not go against the very ideas behind F/OSS in the first place?

      • (Score: 2) by jcross on Monday September 15 2014, @02:04PM

        by jcross (4009) on Monday September 15 2014, @02:04PM (#93436)

        I would say $TECHNOLOGY has for a long time had too many complicated interdependencies for all but a few to really understand, and too many for anyone to understand completely. Personally, even if I had the know-how to audit the systems I use, I have much more enjoyable things to do with my time. I suspect that I'm like most people in that I trust someone else to make sure my systems work right and are reasonably secure. I assume someone will audit it, right? Right? Then something like heartbleed comes along and we all realize how naive that was, to expect that someone, somewhere would have the time and inclination to carefully consider every patch. And from the times I have poked under the hood of this or that piece of FOSS software, I've often been appalled at the code quality but also grateful that someone wrote it and shared it with me, probably without pay.

        So given that I literally do not have the time, even giving my whole life to the cause, to understand, let alone fix, every problem with the systems I use, I'm happy if it just does its job. Say what you will about ChromeOS, but it is really reliable at what it does. Say what you will about pulseaudio or systemd, but so far in my experience so far they do work as well as or better than what came before, and they do it out of the box, without any fiddling. Multiple applications sharing the audio device peacefully! I love using Linux, but I don't miss the days of spending hours learning how something works just so I can make it do what it's supposed to. Maybe it's time we started thinking about the OS more like an appliance that just works, and the really interesting stuff is built on top of that. I want to spend time crafting my sandwich, not sticking a knife in the damn toaster.

    • (Score: 2) by q.kontinuum on Monday September 15 2014, @02:18PM

      by q.kontinuum (532) on Monday September 15 2014, @02:18PM (#93445) Journal

      The "only" problem is the authority about the installed root-certificates. As long as the device-owner (by which I mean the customer, not the vendor!) can install any root-certificate he likes, trusted computing is a nice thing, I would like it a lot. If he can't, this little detail turns it into a desaster.

      But I agree it would be much easier for the vendors to just implement everything nicely and then just change this "little" detail, so I agree we should either fight the beginnings or make sure the right customer protection laws are in place in time.

      --
      Registered IRC nick on chat.soylentnews.org: qkontinuum
      • (Score: 2) by VLM on Monday September 15 2014, @02:50PM

        by VLM (445) Subscriber Badge on Monday September 15 2014, @02:50PM (#93471)

        "As long as the device-owner (by which I mean the customer, not the vendor!) can install any root-certificate he likes"

        The whole concept is a waste of time, because either you don't own your device anymore, or the same idiots who install toolbars and comet cursors and weather bugs will simply add root-certs, bringing you back to where we are, but more complicated, harder to fix, and less useful. Even worse someone will break the system and back door it, but "the computer never lies and it says its trustworthy" so you get a false sense of security. Its literally a waste of time to even try to implement. Assuming you're looking for security and not profitable tivo-ization.

        • (Score: 2) by q.kontinuum on Monday September 15 2014, @03:11PM

          by q.kontinuum (532) on Monday September 15 2014, @03:11PM (#93481) Journal

          Depends how hard it is to add root certificates. This should only be possible at boot time, via an additional HW switch to enable root certificate update, and the switch can be disabled via jumper on board. I'm pretty sure my wife or son, or average secretary, wouldn't go through this just to install skye + "Bing Bar Helper for 3rd party browsert" + "Ask bar". And where it's justified, there is always the option to put a padlock on the casing.

          --
          Registered IRC nick on chat.soylentnews.org: qkontinuum
      • (Score: 2) by tangomargarine on Monday September 15 2014, @04:04PM

        by tangomargarine (667) on Monday September 15 2014, @04:04PM (#93500)

        sudo load fuck_yall_you_just_do_what_i_tell_you.cert

        A lot of developments the last few years have been trying to crowbar us away from the original spirit of computing: This is my hardware. It runs the bits I tell it to. If they don't work, it crashes.

        --
        "Is that really true?" "I just spent the last hour telling you to think for yourself! Didn't you hear anything I said?"
        • (Score: 1) by wantkitteh on Monday September 15 2014, @04:29PM

          by wantkitteh (3362) on Monday September 15 2014, @04:29PM (#93510) Homepage Journal

          That's completely understandable. For the vast majority, computers are the applications you are productive in, not the underpinnings that someone else sets up and maintains for you. Any time spent away from those productive applications is a bad thing that harms your bottom line, so any method you have of trusting your infrastructure even more to reduce preventative maintenance, the better. And yes, I'm disappointed this attitude seems to be popping up in Linux, but I won't be worried until it turns up in Debian Stable standard distros.

          • (Score: 2) by q.kontinuum on Tuesday September 16 2014, @05:25AM

            by q.kontinuum (532) on Tuesday September 16 2014, @05:25AM (#93856) Journal

            I'm worried already, I just maintain that the actual problem is not the implementation of the feature in the Linux kernel but the abusive way it might be used by vendors (e.g. by not allowing the customer to install his own root-certificate).

            --
            Registered IRC nick on chat.soylentnews.org: qkontinuum
    • (Score: 2) by martyb on Monday September 15 2014, @02:39PM

      by martyb (76) Subscriber Badge on Monday September 15 2014, @02:39PM (#93459) Journal

      dublet [soylentnews.org] wrote:

      I mean if you go the whole trust way, you can verify your source code, but how can you trust your compiler [bell-labs.com] [bell-labs.com]?

      I appreciate your thoughtful post - you raise good points and I share your view on the majority of them.

      I called out the above bit because there have been some advances that folks might not be aware of. Fully Countering Trusting Trust through Diverse Double-Compiling (DDC) - Countering Trojan Horse attacks on Compilers [dwheeler.com] by David A. Wheeler.

      It's been a long time since I read it, but my recollection is that he thoroughly and methodically explored the issue and came up with a valid mechanism that he proved would thwart such an attack. HIGHLY recommended reading! But, don't "trust" me — read it yourself!

      --
      Wit is intellect, dancing.
      • (Score: 2) by VLM on Monday September 15 2014, @02:46PM

        by VLM (445) Subscriber Badge on Monday September 15 2014, @02:46PM (#93466)

        Its an interesting technique and probably useful, but if your compiler isn't a dead project, the following is false:

        "Previously-known countermeasures have been grossly inadequate."

        The optimization team and the architecture porting team are going to be really confused and pissed off if what they're specific working on suddenly starts spewing out extra junk that doesn't seem to fit and shows up really weirdly in the profiling runs ("Why does this binary blob only run in the profiler when we compile /bin/login but nothing else?" and "why is /bin/login only 500 bytes on PIC32 or whatever "new" arch, but on i386 it compiles to 75 megs and seems to contain a peer to peer communications system per lsof?" type of commentary).

      • (Score: 2) by dublet on Monday September 15 2014, @03:05PM

        by dublet (2994) on Monday September 15 2014, @03:05PM (#93480)

        I called out the above bit because there have been some advances that folks might not be aware of. Fully Countering Trusting Trust through Diverse Double-Compiling (DDC) - Countering Trojan Horse attacks on Compilers by David A. Wheeler.

        My point was a more general one rather than specifically that attack. There may be a number of these sorts of attacks, for all we know there could be a bug or backdoor in SecureBoot or any hardware device that may be added to the computer to perform verification. After all, how do you trust those that made the hardware and implemented that bit of software? It's already been known that we can't trust any hardware manufacturers [wikipedia.org] to deliver us safe, verified bits of hardware.

        If the hardware can be compromised, how can you even begin to trust the software? It's turtles all the way down, IMO.

    • (Score: 2) by Thexalon on Monday September 15 2014, @02:42PM

      by Thexalon (636) on Monday September 15 2014, @02:42PM (#93462)

      You beat me to it.

      I also want the ability to tinker with my system and fix any problems that come up without having to get approval from somebody.

      Let's say, for instance, that a version of Linux was released that had a backdoor put in by $SPY_AGENCY, and that version was signed and approved to work with SecureBoot. For the sake of argument, let's say I'm the first person to discover the backdoor, so I now try to fix it: I find the relevant code, create a patch that might remove the problem, re-compile, put the new kernel in /boot, and ... whoops, I no longer have a signed and approved version of Linux, so I can't boot my new kernel. Instead, my only recourse is to submit the patch upstream, wait until someone with commit privileges accepts the patch or one that does something similar, wait until the new release is ready and Linus is happy with it, and then wait for the approval process to go through before I can use my machines the way I want to. All this time, there's a backdoor, I know about it, but I can't get rid of it because SecureBoot is forcing me to use a version that I know I can't trust.

      The only way to counter this would be to have a way for me to fool SecureBoot into using my new kernel. But that would mean that whatever I can do, the bad guy can do too (or socially engineer to get a less-than-savvy user to do), which means that SecureBoot doesn't work.

      And to emphasize your last point: True security comes from a lack of trust. I don't trust that somebody who's not invited won't walk into my house and take something. I don't trust that the Nigerian prince who emailed me from @yahoo.com is who he says he is. I don't trust that the files claiming to contain nude pictures of Anna Kournikova really are what they say they are. And I don't trust a major corporation that says, well, just about anything, without some sort of verification from somebody who doesn't stand to profit if the claim is correct.

      --
      The only thing that stops a bad guy with a compiler is a good guy with a compiler.
      • (Score: 2) by urza9814 on Tuesday September 16 2014, @10:10PM

        by urza9814 (3954) on Tuesday September 16 2014, @10:10PM (#94268) Journal

        I find the relevant code, create a patch that might remove the problem, re-compile, put the new kernel in /boot, and ... whoops, I no longer have a signed and approved version of Linux, so I can't boot my new kernel.

        ...at which point you flip the BIOS switch, add your own cert to the trusted list which you should have done from the beginning, and you're back up and running.

    • (Score: 1) by slartibartfastatp on Monday September 15 2014, @09:45PM

      by slartibartfastatp (588) on Monday September 15 2014, @09:45PM (#93653) Journal

      Thanks for the Ken Thompson reference - extremely insightful!

    • (Score: 2) by urza9814 on Tuesday September 16 2014, @10:05PM

      by urza9814 (3954) on Tuesday September 16 2014, @10:05PM (#94265) Journal

      Oh come on. Security comes from many things but not from trust. In fact, not trusting anything, including any signings and verifications is more trustworthy than those signings and verifications. For all you know, they've been faked too.

      While there's some truth to that, it's an entirely unusable philosophy in the modern world.

      So you don't trust anyone. Right, have you verified every single line of code in the operating system and all software you're using? That alone would be pretty much impossible. But that's just the beginning. What about the processor? Motherboard? All the other silicon? Have you personally audited the schematics for all your hardware? Have you personally audited the fabs they were produced on?

      In the end, you have to trust somebody or something. And at that point, signing is about the best solution we have, because you need to know that what you're running comes from that institution you've decided to trust and hasn't been modified in transit or since installation.

      That doesn't mean losing control over it. The difference between Linux and Windows or OSX shouldn't be that the proprietary ones use signed code and the open source ones don't. That's just giving up. That's saying you want the open source one to be an insecure hobbyist toy. All the open source ones must do is *provide choice*. Let the user choose which signatures to trust. As long as that is true, there's absolutely no negative to signed code.

    • (Score: 2) by No.Limit on Thursday September 18 2014, @07:49PM

      by No.Limit (1965) on Thursday September 18 2014, @07:49PM (#95172)

      You also never use HTTPS?, because it's safest to trust no certificates at all?

      Seriously guys?, this is EXACTLY the same concept like HTTPS. You have a chain of trust and well that chain's gotta start somewhere.

      Whether it starts at the browser provided CA (certificate authority) list or from some other source (not quite clear in systemd's case) doesn't really make a difference.

      Because a good implementation will let you choose (yes, that's right, you can have choice and openness with signed software) the root of your trust (the CAs). So yes, you can still boot whatever you tell it to.

      If you have an implementation that doesn't let you do that, then it's a problem with the implementation, but not with the concept.

      Hell, you trust your repository every day to deliver the right packages (they're also signed). Now you can trust them right from the start (the boot). No more master boot record root kits.

  • (Score: 3, Insightful) by Lagg on Monday September 15 2014, @12:36PM

    by Lagg (105) on Monday September 15 2014, @12:36PM (#93395) Homepage Journal

    This screenshot [imgur.com] I took of my feed reader pretty much says it all. You guys get this close to creating solid points and well deserved criticisms of systemd, but then you go way off course. This is a level of irrationality usually reserved for actual Tivos and Microsoft doing something stupid. Guess what though, in both of those cases it's mostly proprietary software. Why are people forgetting that we can fix this stuff? I've even been poking around the systemd code for another project I'm doing and it seems like there's a lot of potential to split systemd up into separate but useful daemons that can be distributed independently. Even the project dir layout lends itself to such things.

    --
    http://lagg.me [lagg.me] 🗿
    • (Score: 0) by Anonymous Coward on Monday September 15 2014, @01:23PM

      by Anonymous Coward on Monday September 15 2014, @01:23PM (#93422)

      Why are people forgetting that we can fix this stuff?

      Because people feel this is:

      • a repeated pattern,
      • a miscarriage not intended to be fixed,
      • not their decision
      • a cause of divorce with their distribution in love.
    • (Score: 2) by Hairyfeet on Monday September 15 2014, @01:53PM

      by Hairyfeet (75) <{bassbeast1968} {at} {gmail.com}> on Monday September 15 2014, @01:53PM (#93429) Journal

      Really? So you personally have the time AND the coding skillz to 1.- Do a complete rewrite of systemd, along with Secureboot or any other "trusted computing" crap they shoehorn in 2.- Rewrite anything that ends up depending on #1 (which the way systemd seems to be growing could be quite a lot in a year) and along with all this you ALSO have time and the skillz to 3.- maintain all of the above when new versions of #1 come out?

      Of course IRL you are probably expecting some mythical "other" to do the work FOR you which as we saw before with the not alpha quality Pulse being shoved into all the mainstream distros and now the bandwagon hopping of systemd is an expectation that will more likely go unfulfilled. You see this is the problem when some big muckety muck decides "it shall be thus" because the users tend to get ignored and the muckety mucks get their way, users be damned.

      --
      ACs are never seen so don't bother. Always ready to show SJWs for the racists they are.
      • (Score: 2) by Lagg on Monday September 15 2014, @03:04PM

        by Lagg (105) on Monday September 15 2014, @03:04PM (#93479) Homepage Journal

        Where did I say I have the skills to do anything. I mean I guess I could take it as a compliment that you think me poking around the code means I'm doing or will do something major but that isn't the case. I'm just saying that from the looks of it there is a lot of potential there that is being ignored or damaged by hyperbole like what you're doing, and no I don't expect someone else to do the job for me. What I do expect is people to work together and start making valid technical arguments and that just isn't happening. No one is bothering to even look at things as basic as the journal file format which is one of the bigger complaints. People basically can't think of any real argument so go "I uh... *mumble stutter* JOURNALS ARE BINARY". The journal was just an example (and one reason I was poking around the code) but that's how it keeps going. Stumbling over some completely bullshit argument using keywords that look nebulous just so they can return to attacks on character or politics. It's stupid and I expect better out of people.

        and as an aside as I expected after reviewing the journal code (which is mostly contained in journal/journal-def.h for the structs for object headers and such and journal-file.c for the implementation itself) most people's arguments are bullshit and the comparison to NT's event logs are completely uncalled for. I've seen some pretty ridiculous theories ranging from intentional obfuscation of the format despite it being laid bare in 3 files at most to it being an OOXML-like convoluted format just because it's ad-hoc. That pretty much goes for everything else too. No one is looking at the finer technical points of systemd and its code (which deserve many a criticism believe me), it's just politics after politics after character attack after politics. And people wonder why the maintainers are ignoring users. Because of shit like what you're doing right now.

        I didn't like that the spec for the journal objects didn't make it clear that they're 64 bit aligned though. I'll say that much. I mean they did say that structures were 64 bit aligned but I didn't think that applied to the payload as well. It really threw me off when I wrote a quick little parser. Basically it'll pad out each object to ((size + (unsigned long long)7) & ~(unsigned long long)7)

        --
        http://lagg.me [lagg.me] 🗿
        • (Score: 2) by Hairyfeet on Monday September 15 2014, @10:54PM

          by Hairyfeet (75) <{bassbeast1968} {at} {gmail.com}> on Monday September 15 2014, @10:54PM (#93699) Journal

          You want your words quoted? okay you asked for it "Why are people forgetting that we can fix this stuff? I've even been poking around the systemd code for another project I'm doing and it seems like there's a lot of potential to split systemd up into separate but useful daemons that can be distributed independently."

          Again who EXACTLY is gonna do this? Who is this mythical person? Is it you? Is it the community which we saw didn't do a damned thing when Pulse was jammed into every mainstream distro when it wasn't alpha quality and instead invoked TMRepo meme #23 Linux supports more hardware than Windows [tmrepository.com] along with a classic, #6 Linux Friendly hardware [tmrepository.com] and neither of which explained WTF ARE THE DISTROS STUFFING ALPHA QUALITY SHIT INTO MAINSTREAM FOR and nor did it change shit, Pulse is slightly better, SLIGHTLY more stable, but when you upgrade the distro what will break every. single. time? Pulse.

          So you say "hey this buttfucking by RH forcing shit that the users don't want into critical subsystems isn't a problem because ,hey we have nothing better to do, we can fix it!" and I'm wanting to know who the fuck is we kemosabe? Is it YOU, do you have NAMES of those that will fix it? Or should we place it next to santa and the easter bunny on the mythical people list? Because history does NOT support your assumption, see Pulse as just the latest example if it comes down to you or the high muckety mucks you WILL take what you are given and STFU or even try to spin being ignored and force fed as a good thing which....damn makes you just like Windows 8 Metro defenders, wow history does make for strange bedfellows. Of course the Windows users have the advantage of voting with their wallets, see how Win 9 is just Win 7 with speed boosts, whereas you can scream about pulse and systemd until the cows come home, the devs have ZERO reason to give a fuck about your opinion. So show me the mailing list, who EXACTLY is gonna fix all this garbage?

          --
          ACs are never seen so don't bother. Always ready to show SJWs for the racists they are.
          • (Score: 0) by Anonymous Coward on Wednesday September 17 2014, @03:48PM

            by Anonymous Coward on Wednesday September 17 2014, @03:48PM (#94590)

            What fucking garbage? Pulse works much better for me than bare ALSA ever did -- and I'm a pro-audio guy so I'm hard to please -- and lately I've been getting into learning systemd, which is optional for me at the time because I use Ubuntu, and guess what? I'm very much enjoying it! It's like my computer is finally becoming what I thought a decade ago computers would be like in the future.

            Garbage is the logic you all use to bitch and moan about having your 70's tech replaced with something better suited to modern expectations of what a computer should do.

            (By the way, I've never had Pulse break on an update. Actually, I never had Pulse break at all. All the failures I've seen are related to ALSA not being properly configured for the hardware and have nothing to do with Pulse.)

            PS. I know Hairyfeet won't read this post, it's meant for everyone else.

    • (Score: 1) by jbernardo on Monday September 15 2014, @01:55PM

      by jbernardo (300) on Monday September 15 2014, @01:55PM (#93430)

      Wow,
      Seems like I got myself a stalker!

      What is wrong with what I wrote in phoronix? Isn't it the corollary of having everything signed and "tamper proof" that only the manufacturer/key owner can change anything, and as we see on smartphones, there isn't much pressure to keep releasing software updates after a couple of months?

      • (Score: 2) by Lagg on Monday September 15 2014, @02:51PM

        by Lagg (105) on Monday September 15 2014, @02:51PM (#93472) Homepage Journal

        Er, no, I'm not familiar with you. I just comment on articles I find interesting and try to keep doing so to keep the discussions alive. I often am the first or one of the first posters so it might seem like I'm singling you out but no. It's just another article in a sea of them. You're not really making my point about conspiracy theories any less valid with the implication that I'm stalking you. It also kind of damages your summary.

        --
        http://lagg.me [lagg.me] 🗿
        • (Score: 1) by jbernardo on Tuesday September 16 2014, @03:40AM

          by jbernardo (300) on Tuesday September 16 2014, @03:40AM (#93830)

          The "stalking" part was a joke, maybe not too obvious. I was more interested in why you decided that what I wrote was a conspiracy theory.

      • (Score: 2) by choose another one on Monday September 15 2014, @06:32PM

        by choose another one (515) Subscriber Badge on Monday September 15 2014, @06:32PM (#93543)

        Isn't it the corollary of having everything signed and "tamper proof" that only the manufacturer/key owner can change anything, and as we see on smartphones, there isn't much pressure to keep releasing software updates after a couple of months?

        Simple way to check if your corollary actually is one - how long has apt had secure package signatures ? What has happened in that time ?

    • (Score: 1) by arashi no garou on Monday September 15 2014, @04:46PM

      by arashi no garou (2796) on Monday September 15 2014, @04:46PM (#93515)

      I've even been poking around the systemd code for another project I'm doing and it seems like there's a lot of potential to split systemd up into separate but useful daemons that can be distributed independently.

      Potential? Yes. Motivation by the devs? No way. They want to keep it monolithic and complicated. Anyone who tries to bring up discussion of what you suggested gets derided as a conspiracy theorist and sent on their merry way. People who submit valid bug reports are told in no uncertain terms that bugs will either be ignored or coded around, never fixed, because "we don't know how" or "it's too hard". They have built their own Tower of Babel and by the time they realized how bad it was, it was too late to tear it down. Now they feel they have to just keep laying brick after brick and hope it doesn't collapse under its own weight. Meanwhile, they have somehow convinced the major distro maintainers that theirs is the One True Religion, so now we all have to deal with this mountain of horse shit.

      It's disgusting and so anti-*nix, but there's nothing us Normals can do about it.

  • (Score: 4, Interesting) by Bob9113 on Monday September 15 2014, @12:42PM

    by Bob9113 (1967) on Monday September 15 2014, @12:42PM (#93403)

    We want our images to be trustable (i.e. signed).

    He wants the OS image to be trustable, ie: signed. Shit. I can't say it any simpler than that.

    He wants you to be able to check the signature on the binary so you know the NSA didn't MiTM your download or modify it after it was installed. That would be a good thing, like the signature checks when I run Apt.

    Whether the BIOS refuses to run unsigned code or whose list of signing keys it trusts is a separate question. I *hate* the very idea of a BIOS that obeys someone other than me. To me, that is a broken BIOS. But that's not what Poettering is talking about. He wants to sign his kernels so you can choose to verify their authenticity if you wish.

    • (Score: 0) by Anonymous Coward on Monday September 15 2014, @01:14PM

      by Anonymous Coward on Monday September 15 2014, @01:14PM (#93416)

      He can sign his images all he wants to, but don't expect me to have to put up with secureboot so that he can indulge his cert fetish. The NSA isn't MiTMing his images anyway: they might have paid his staff to hide obscure bugs in the source code, or they might have pwned something upstream in the development cycle, and they almost certainly have a backdoor built into the secureboot firmware, but MiTMing his lousy images would be crude and artless.

      • (Score: 0) by Anonymous Coward on Wednesday September 17 2014, @04:07PM

        by Anonymous Coward on Wednesday September 17 2014, @04:07PM (#94599)

        Yeah, thiefs don't pick locks anyway, they force you at gunpoint to let them enter your house with you, or they just smash windows, and the government can just tow your car anywhere they want without having to open it.

        So, if you'll excuse me, I'll go remove all the locks from everything that has a doorlock. They're clearly just a fetish thing, and I don't want to be labeled a fetishist! I'm sure that nobody will open the doors and take my stuff because, as you kindly pointed out, that would be crude and artless, and obviously nobody is going to do that.

  • (Score: 1) by fbscarel on Monday September 15 2014, @12:49PM

    by fbscarel (2358) on Monday September 15 2014, @12:49PM (#93405)

    Good thing I'm already using OpenBSD. Don't know who are these people who say "we want our images to be trustable".
    Seems like "post-Snowden" is the new "think of the children".

    • (Score: 0) by Anonymous Coward on Monday September 15 2014, @01:23PM

      by Anonymous Coward on Monday September 15 2014, @01:23PM (#93421)

      I've missed the BSD trolls, I thought you were dead!

      • (Score: 2) by Marand on Monday September 15 2014, @03:04PM

        by Marand (1081) on Monday September 15 2014, @03:04PM (#93478) Journal

        I've missed the BSD trolls, I thought you were dead!

        They're only dead if netcraft confirms it.

    • (Score: 0) by Anonymous Coward on Monday September 15 2014, @06:48PM

      by Anonymous Coward on Monday September 15 2014, @06:48PM (#93549)

      Funtoo (Gentoo derivative) refuses to even have systemd in its repository.
      Same for LSD Linux (Less System D).

      Gentoo, Slackware, and CRUX don't use systemd by default but do have it in their repos.

      ...then there's kFreeBSD from Debian.

      ...and, of course, Linux From Scratch.

      For starters, stay away from GNOME 3.

      -- gewg_

  • (Score: 0) by Anonymous Coward on Monday September 15 2014, @12:50PM

    by Anonymous Coward on Monday September 15 2014, @12:50PM (#93408)

    I want a trusted system (no rootkits, no trojans).
    I also want control over the bios keys.

    It is possible to have a trusted system than can be controlled.

  • (Score: 2) by gman003 on Monday September 15 2014, @01:34PM

    by gman003 (4155) on Monday September 15 2014, @01:34PM (#93424)

    Question: With all of this, will I still own and control my own hardware? ie. do I control which sources are trusted? Do I have a way to compile and run my own kernel and code?

    If yes, then I think it's a good thing. After all we've seen, I would really be surprised if the NSA *isn't* trying to put hacked kernels onto every system they can. This would be a way to block that, or at least detect it. No different in principle than comparing SHA1 checksums. With control over which certs are trusted, I could even use it to protect self-compiled systems, or to revoke trust from any source that gets hacked.

    If no, then go fuck yourself with a rusty rake.

  • (Score: 0) by Anonymous Coward on Monday September 15 2014, @02:34PM

    by Anonymous Coward on Monday September 15 2014, @02:34PM (#93454)

    The systemd cabal (Kay Sievers, Harald Hoyer, Daniel Mack, Tom Gundersen, David Herrmann, and yours truly)

    RUN FOR THE FUCKING HILLS! ARGHHHHHhhhhhhh......

  • (Score: 3, Insightful) by opinionated_science on Monday September 15 2014, @02:41PM

    by opinionated_science (4031) on Monday September 15 2014, @02:41PM (#93460)

    I detect a rewriting of history here.

    The problem was not EFI, accept the fact is was a blatant attempt at corporate control from M$ (and possibly Intel).

    If there was a FOSS Bios, and you can choose the signing keys there is no problem.

    The problem was Micro$oft managed to get their keys to be the only ones. Redhat (other distros?) bought one of their keys on behalf of the Linux community.

    UEFI is a broken system, because like everything else companies do working >0% of the time is the only metric of success, the desire to make money for no extra work.

    All the packages on my system are already signed. The only binary blob I have is the Nvidia driver. So long as I can rebuild the kernel, sign it, and boot it, I don't see the problem.

    • (Score: 3, Informative) by LoRdTAW on Monday September 15 2014, @03:33PM

      by LoRdTAW (3755) on Monday September 15 2014, @03:33PM (#93489) Journal

      If there was a FOSS Bios, and you can choose the signing keys there is no problem.

      There is: http://www.coreboot.org/ [coreboot.org] + http://www.coreboot.org/TianoCore [coreboot.org]

      We are just missing useful, modern hardware utilizing such software.

      • (Score: 2) by opinionated_science on Monday September 15 2014, @03:46PM

        by opinionated_science (4031) on Monday September 15 2014, @03:46PM (#93495)

        i know it is a bit sad. my hp desktop has a broken bios, probably due to ufi and linux. Fortunately my linux drive was "approved" before it lost its marbles so at least I can boot!!

        a shout out to the work of the coreboot folks. I would try and buy my next machine that booted it, if I knew what to buy!!!

  • (Score: 2) by gallondr00nk on Monday September 15 2014, @03:15PM

    by gallondr00nk (392) on Monday September 15 2014, @03:15PM (#93483)

    Now, with the name-spacing concepts we introduced above, we can actually relatively freely mix and match apps and OSes, or develop against specific frameworks in specific versions on any operating system. It doesn't matter if you booted your ArchLinux instance, or your Fedora one, you can execute both LibreOffice and Firefox just fine, because at execution time they get matched up with the right runtime, and all of them are available from all the operating systems you installed.

    So the plan is to match up the versions on bleeding edge rolling distros with regular release distros? This sounds like an entirely painful proposition.

    To my barely technically literate brain, some of this sounds a little like Windows AD user profiles - shared home directories combined with standardised installs, though in this case using btrfs. It's not an outright bad idea in my opinion*, but how they'll manage to make it work across distros I have no idea.

    One thing I would like to know is where this sudden craze for standardisation came from.

    *though by the time Pottering has gotten through with it, I have no doubt it will be.

    • (Score: 2) by opinionated_science on Monday September 15 2014, @04:42PM

      by opinionated_science (4031) on Monday September 15 2014, @04:42PM (#93513)

      I'll help you as best I understand it.

      Currently , all distros pick packages and compile them to work together and release it as a serious of "dependencies" that is what the packages you download is . In RPM or DEB format it contains a) the compiled files b) a list of dependencies to make those files work.

      Hence, since all of the packages are constantly evolving, current distros have many possible compatibility problems. A good example of this is glibc - all distros break when glibc breaks.

      What is proposed for BTRFS only works because of dedup and crypto support. Essentially keeping only differences not all stuff and a way of making sure it is not corrupted. You can actually have pointers to ten versions of glibc, without using 10x the space. Linkers will pick the right one (I hope!!).

      In this scheme then, instead of distros giving a bunch of packages with a bunch of dependencies internally resolved. Distros could give you the entire distribution as a volume, composed instead, of named versions of individual packages. Booting off it would be like booting a LIVE DVD!!! Packages are on the disk EXACTLY as the distro wanted them to be. GRUB would mount and boot root=/namespace.

      The example of this is given as , your "runtime" is that stuff that is installed under /usr all belongs to the same set.

      For example, you decide to install RedHat distro. You get this binary tree and the blocks are assembled and made to look like "/usr/" and if you look in "/usr" all you will see if Redhat compiled software. Suppose now, you want to run an application which OpenSuse has a specific version you want to use. You would simply import the "Opensuse namespace" and select the version of files needed for Application X. This would then be mountable on your Redhat distro (say as /usr/local , and links generated perhaps in /usr/ if it doesn't exists - you get the idea). The point is there are a lot of similarities between OpenSuse and Redhat, and the namespaces will only bring in what is required.

      The tricky parts are probably the kernel and compilers. Of course if you need functionality in a running system, only a kernel module can produce it.However, it is entirely plausible that kernels become versioned too, especially since Linus has declared that changing the ABI to break user code, is a bad thing.

      For compilers it is pretty important the compiler version is included in the namespace. The details are quite important!!

      That's how I understand it. Nothing changes if you want to compile a package from source, it is clear the tools to add external code can be produced the same way.

      The big problem is getting BTRFS stable enough to trust it to deploy on a large scale on many platforms.

        But that is out of my experience...

      • (Score: 1) by pvanhoof on Monday September 15 2014, @05:54PM

        by pvanhoof (4638) on Monday September 15 2014, @05:54PM (#93530) Homepage

        The support for lightweight containers in systemd doesn't mean it will be running multiple kernels. Just multiple userspaces. A lightweight container that runs its own kernel would instead be called a virtual machine. I can imagine QEmu support in systemd someday so that it doesn't matter whether you make systemd nspawn a entire VM or a lightweight container, though.

        I also don't think it's immediately the idea to run all software in lightweight containers. Just a bunch of them. I'm hoping that the kdbus ipc will allow running having dbus IPC routing between the containers and dbus service activation instead of having to use systemd-nspawn to bring up a NetworkManager configured to run in a container.

  • (Score: 1, Insightful) by Anonymous Coward on Monday September 15 2014, @06:17PM

    by Anonymous Coward on Monday September 15 2014, @06:17PM (#93537)

    1. pottering works for redhat.
    2. redhat's biggest customer is the us dod.
    3. us dod is part of the same gov as the nsa.
    4. connect the dots.

    • (Score: 2) by mtrycz on Tuesday September 16 2014, @09:25AM

      by mtrycz (60) on Tuesday September 16 2014, @09:25AM (#93898)

      I have a growing anti-Pottering sentiment, and was going to show some charts to my friends, but I can't find any data on how much of Red Hat's revenue comes from US Military. And I mean "data". Not something that someone has said sometime. Couldn't find it anywhere, tho. Do you have some links?

      --
      In capitalist America, ads view YOU!
  • (Score: 2) by unitron on Tuesday September 16 2014, @01:20AM

    by unitron (70) on Tuesday September 16 2014, @01:20AM (#93761) Journal

    Either do not purchase a TiVo or do not expect to be able to get it to do stuff that TiVo didn't intend for it to do. Nothing TiVo ever did prevented anyone from running Linux on other devices.

    A TiVo may have some "computer-ish" characteristics, but they don't advertise or market it as a computer.

    Of course the use of open source Linux in conjunction with their closed source proprietary software made it possible for some folks to do some cool stuff with TiVos that TiVo, Inc. never intended or planned on, but I'm pretty sure the worst thing they ever did to anybody where that was concerned was to point out that opening up the box voids the warranty.

    --
    something something Slashcott something something Beta something something
    • (Score: 0) by Anonymous Coward on Tuesday September 16 2014, @02:55AM

      by Anonymous Coward on Tuesday September 16 2014, @02:55AM (#93802)

      Either TiVo should not have developed a product using free software, or they should honour the license as the developers intended. Nothing the GPL ever did prevented TiVo from developing their own software for their devices.

      Linux might have some "operating system-ish" characteristics, but they don't advertise it as something you can create close-source products out of.

      Of course their adoption of open source allowed them to quickly build a product that upstream developers might never have thought of, but I'm pretty sure that the worst thing they ever did was to ignore the fucking software license.

      • (Score: 2) by choose another one on Tuesday September 16 2014, @02:00PM

        by choose another one (515) Subscriber Badge on Tuesday September 16 2014, @02:00PM (#94006)

        The software licence in question was (and is, at least in the case of Linux) GPLv2. That version of the GPL makes no mention whatsoever about whether or not the device/environment on which the program runs is itself open and modifiable (so that any modified version of the program can be run on the device). The fact that GPLv2 didn't prohibit what TiVo did is further evidenced by the changes made in GPLv3 precisely to prohibit it (which would clearly be unnecessary if GPLv2 already prohibited it).

        TiVo is neither the first nor the only one to do what they did, building a device that would only run certain versions of (some GPLv2) software. Read up on why both Apple and BSD stopped using newer GCCs (and stopped contributing) and moved to LLVM instead, for a start. And clearly Android would not exist and be based on Linux if GPLv2 did not allow it.

        But the final word is, as you say "they should honour the license as the developers intended". Linus uses or has used both TiVo and Android and has spoken in favour of both. He also has spoken _against_ the anti-TiVo changes in GPLv3 and Linux remains GPLv2. Linus is also on record as saying that the choice of GPL v2-only for Linux (rather than "or later version") was deliberate to avoid exactly the kind of "I am altering the deal" that RMS/FSF later engaged in with GPLv3.