back to article Chrome, Debian Linux, and the secret binary blob download riddle

The Debian Project thinks it's fixed an issue where Google's Chromium web browser snuck proprietary code into the fiercely Free Software oriented Debian Linux distro. That hasn't stopped Debian users from wondering how the issue got past project maintainers in the first place. Debian user Yoshihito Yoshino first raised the red …

Page:

  1. This post has been deleted by its author

    1. Anonymous Coward
      Anonymous Coward

      "Binaries that were not compiled under your complete control should be considered compromised."

      I run Gentoo on quite a few systems. That means that I generally have a fair idea what is on the system, mainly though having to fix some snags that are frankly ... interesting. However, on the laptop I'm typing this, I've got EIX_LIMIT=0 eix -I --only-names | nl = 1956 separate bits of software. NEARLY 2000 lumps of code from a few Kb to LibreOffice which really isn't a few Kb and stresses a Core i7 for nearly an hour!

      I actually know the shape of many of those things flying through autotools, moc, gcc and lots of other things, streaming through my alpha blended konsoles, rendered on the side of an eight sided "cube" when I get bored.

      I still don't trust much of it - how can I? I still use it though 8)

    2. asdf

      >Binaries that were not compiled under your complete control should be considered compromised.

      Sadly that often includes the only video drivers that give you more than VESA level acceleration (xorg nv drivers you suck dick, lmao at dragging a partially transparent terminal window around).

      1. alun phillips
        Trollface

        If youre serious about security

        Why would you be running a gui, terminals don't require graphic acceleration.

        1. asdf

          Re: If youre serious about security

          >Why would you be running a gui, terminals don't require graphic acceleration.

          Joke aside absolutely true at work. Doing say banking through lynx viable not so much.

          1. Anonymous Coward
            Anonymous Coward

            Re: If youre serious about security

            "Doing say banking through lynx viable not so much".

            Pardon my ignorance but what is it that stops a secure web application working with (or being implemented with) lynx?

            Is it just lack of support for the shiny that the bank has designed in (but which isn't actually necessary)?

            Or are there fundamental things, maybe security related things, missing from lynx?

            If stuff is missing, what is it, and what would it take to eithe (a) add it in if it is truly necessary (b) remove it from the webstuff in question if it's not actually necessary?

            Suggestions welcome.

            KISS, and all that.

            1. Anonymous Coward
              Anonymous Coward

              Re: If youre serious about security

              Well, there IS such a thing as NECESSARY complexity, KISS be damned.

              How about a CAPTCHA, for starters, for when a second factor isn't an option? Text consoles limit the ability of CAPTCHAs to not be machine-readable (and thus prone to pwning).

              Second, bank sites tend to present their data in tabular formats which can be tricky to present on a fixed-character-width console, These tables can also be interactive to provide context-sensitive menus and options when you select an entry in the table (take bill pay, where you can be prompted to enter a payment or whatever). It may be graphical, but it's also hardly a bell and whistle as any other means to achieve many of these functions would quickly get unnecessarily complicated.

              1. Anonymous Coward
                Anonymous Coward

                Re: If youre serious about security

                I'm back.

                Even I know that:

                Re Captchas

                (a) graphical captchas are outdated although quite a few places still use them

                (b) alternatives to graphical captchas are trivial (what is ten minus four ?)

                (c) I've never seen a captcha used for security, only for bot-avoidance and the like

                Re banking etc

                (a) tabular formats are often *easier* in monospace font

                (b) point taken re context sensitive menus but my bank (not a minnow in the online banking industry) manages without any of that

                Maybe many readers are a little young to remember this, but most of HTML started life as little more than a slightly smarter version of ANSI X3,64 (aka VT100 cursor control; look it up). With very obvious and frequently very shiny (and now frequently very vulnerable) exceptions as time goes by.

                Thanks anyway. Keep 'em coming.

                1. Charles 9

                  Re: If youre serious about security

                  "alternatives to graphical captchas are trivial (what is ten minus four ?)"

                  Most alternatives that use text can be interpreted by a natural language processor. As in run that CAPTCHA through Google and you're likely to get an answer.

                  "tabular formats are often *easier* in monospace font"

                  Not for DYNAMIC content. When HTML was first developed, it was designed for STATIC content. Indeed, how does Lynx handle modern CSS styles where things can be revealed and hidden dynamically, which DOES have practical uses regarding context? Put it this way. I once had to do certain transactions by telephone. And that was my only option as I was away for a an extended period, my nearest branch two hours away and I didn't have a car. Compared to that, I consider online banking heaven-sent in terms of practicality.

                  1. Anonymous Coward
                    Anonymous Coward

                    Re: If youre serious about security

                    "Most alternatives that use text can be interpreted by a natural language processor. As in run that CAPTCHA through Google and you're likely to get an answer."

                    Indeed. I know that. I also know it's easy for me to interpret Google's answer, not least because I already know the answer, whereas if the question had been (say) "what does lentement mean?" it would have been less obvious.

                    What I don't know is how easy it is for a program to interpret Google's various answers to "what is ten minus four".

                    Static vs dynamic content: better presenation-layer people than me will think of something. So long as it doesn't even vaguely resemble the Met Office's nightmare of a website, which I assume is an example of what's meant by "dynamic content".

    3. Fibbles

      Unless you're reading every line of code how is this any safer than downloading binaries from repositories? Your security is dependent on other people in both cases.

      1. Steve Knox

        "Other people" != "other people"

        Unless you're reading every line of code how is this any safer than downloading binaries from repositories? Your security is dependent on other people in both cases.

        In the closed case, your security is dependent on a small* group of people with a vested interest in not disclosing any security issues (deliberate or not) in the code.

        In the open case, there is (at least the potential for) a larger* group of people with a greater motivation for disclosing and/or fixing security issues.

        *Not small vs large in terms of physical size or even necessarily quantity, but in diversity of goals and drivers.

      2. Christian Berger

        "Unless you're reading every line of code how is this any safer than downloading binaries from repositories?"

        It's much harder to deliver malware in sourcecode than it is in binary form, as with the source you are much more likely it'll be found.

        Of course complexity is the main culprit here. Web standards, and therefore browsers, are just _way_ to complex these days. That means you need way to much code to implement them, making it hard to make truly free software in a sense of software you can participate in easily.

      3. Anonymous Coward
        Anonymous Coward

        @Fibbles

        Unless you're reading every line of code how is this any safer than downloading binaries from repositories? Your security is dependent on other people in both cases.

        I agree with you where, as I call it, 'hands on' security is concerned. If there's a small programming error in a program somewhere then it's quite unlikely that anyone will notice. I hate to drag up disasters from the past, but the Debian OpenSSL debacle really showcased this. This goes double in my opinion because the changes were done by a Debian package maintainer and were also applied to the encrypting engine. I'd like to think that the engine is the first place people would look for issues.

        However, there is definitely a sense of security to be found in compiling your own software, in my opinion of course. I'm a FreeBSD user and all the servers I run have been compiled from scratch (so, the base OS has been reconfigured and compiled) as well as all the software I use on it (Ports collection).

        Here's the thing: at the very least you can see for yourself that the software compiles, and without too many intrusive "hacks". What if a package maintainer or developer found something odd and instead of fixing the programming error they simply used other compile flags to "make it work"? Wouldn't be the first time, and this approach is a sure way to check for it.

        However, that's still in the eye of the beholder.

        The main security advantage can be found in customizing. If you only use default settings then any intruder will know exactly where to look and how to accomplish certain tasks. But the moment you change those defaults to fit your own environment this task can sometimes become a lot harder. At the very least you'll stall or stop automated processes such as rootkits.

      4. Doctor Syntax Silver badge

        "Unless you're reading every line of code"

        Not only reading but understanding. That's the tricky bit.

      5. John Sanders
        Linux

        Reading every line of code...

        That is not the problem, in absolute terms yes you're right, the sentence is correct:

        "Unless you're reading every line of code how is this any safer than downloading binaries from repositories"

        Where the logic breaks is here:

        If I have the source code I can inspect it if I suspect foul play, I can compile it myself and be 100% sure that the "blob" is not compromising my system.

        When you have no such source code available all I can do is guess and distrust, I can not verify anything.

        The source is important not because you are going to check every single line of all the packages you run in Debian, but because if you need to check anything for security or bug fixing reasons, you should be able to.

    4. K

      "should be considered compromised"

      Love the principle, but unless the person compiling the binaries combs through every line of code, this is a false sense of security, even the most innocuous looking code could have some underlying purpose.

      1. This post has been deleted by its author

        1. John Sanders

          Source code

          """So, overall, this idea that obtaining source code and compiling it yourself gains you nothing, is just an excuse for lazyness in a lot of situations."""

          Sometimes yes, but the majority of the time is people who doesn't understand what FOSS is, or people with a vested interest on other people not knowing (AKA Monopolistic vendors).

      2. Dazed and Confused

        How can you trust...

        "should be considered compromised"

        Even if you've got the source code how can you trust:

        The FW on your box?

        The boot strap

        The compiler? Dennis Richie demonstrated decades ago how to propagate viruses through the compiler by making the compiler recognise when it is recompiling itself and then inserting the virus. You can then remove this hack from the compiler source code and it will continue to propagate through every subsequent version of the compiler built by itself or it's descendants.

        How do you trust the CPU? or any of the other HW.

        Remember it isn't paranoia if the world is out to get you.

        1. Allan George Dyer

          Re: How can you trust...

          @Dazed and Confused - You're thinking of Ken Thompson's "Reflections on Trusting Trust", https://www.ece.cmu.edu/~ganger/712.fall02/papers/p761-thompson.pdf

          but apparently there's a fix for that by David A. Wheeler, http://www.acsa-admin.org/2005/abstracts/47.html

        2. Charles 9

          Re: How can you trust...

          "The compiler? Dennis Richie demonstrated decades ago how to propagate viruses through the compiler by making the compiler recognise when it is recompiling itself and then inserting the virus. You can then remove this hack from the compiler source code and it will continue to propagate through every subsequent version of the compiler built by itself or it's descendants."

          Except someone found a solution. All it requires is one known-safe compiler and then you can cross-compile the source code several times with differing compilers to see if the compiler's tainted.

          As for the hardware, microscopy perhaps?

    5. alcalde

      I'm a full-time Linux user for five years, and I'm still surprised by the amount of paranoia and tin-hat thinking in the Linux community. Assuming the least likely thing is the most likely thing is the realm of conspiracy theories. Unless you're a known target of industrial or political espionage - bank, defense contractor, etc. - one should assume all code is exactly what it appears to be unless you have an actual reason to believe otherwise. Who realistically thinks they're important enough that Google wants to personally spy on them? This tempest-in-a-teapot stuff distracts us from things that are really important - such as the forthcoming Windows 10 and the degree to which it has borrowed from Linux, from package management to virtual desktops to a free upgrade, and the potential rehash of the UEFI-may-lock-out-Linux problem that surfaced with Windows 8. That will really affect Linux users. "OK Google" has no bearing of any import whatsoever.

  2. Anonymous Coward
    Anonymous Coward

    How did it get past the Debian maintainers?

    The same people who let systemd past despite known major flaws, privacy issues and WONTFIX-obsessed devs?

    Gee, I wonder...

    1. Tomato42
      Facepalm

      the world is changing, get over it

      1. Craig 2

        In my (admittedly limited) opinion, it looks like it's changing for the worse, and I hope nobody "gets over it".

      2. Anonymous Coward
        Anonymous Coward

        You're right, change is all that matters! Why should I care about maintainability, reliability and simplicity? Lets just change everything! Doesn't matter to what, just so long as it's different to what was there before!

        1. dlc.usa

          Re: Change Is All That Matters

          Note to DDs: anything_newer != always_better ;

          Funny definition of evil Google has there.

          That's only the second time I've upvoted an AC comment.

      3. asdf

        >[Linux] is changing, get over it ...

        and come on over to *BSD and Lumina. You will appreciate still being able to recognize the POSIX in 3 years plus its virtually guaranteed to be systemd free for many years to come.

        1. Hardrada

          Agreed. I'll even add to your list of BSD virtues:

          OpenBSD has the most reliable package system I've used. Zero problems. Ever.

          They don't just write cool software; they write software when a new solution is needed. For example, security issues in NTP were dealt with in OpenBSD a decade ago: https://en.wikipedia.org/wiki/OpenNTPD

          All three of the main BSDs have scriptable device notification systems that are easy-peasy to adapt or troubleshoot. (FreeBSD and OpenBSD had devd/hotplugd when Linux was still stuck with HAL.)

          Both NetBSD and OpenBSD have no-nonsense installers. All of the BSDs make it easy to install a stripped down base system and customize from there. (FreeBSD gives you vanilla packages like Slackware, has dependency checking out-of-the-box, isn't as bleeding edge as Gentoo, nor as conservative as stock Debian.)

          FFS and UFS are rock-solid. You can get journaling (and a lot more) if you want it, but even before that, soft updates solved the biggest problem (FS corruption on interrupted async writes) with a dead-simple, low overhead system.

          1. asdf
            Headmaster

            minor quibbles

            >FFS and UFS are rock-solid.

            Yep but darn do I love ZFS (which runs out of the box on PC-BSD). In fact, PC-BSD being based off FreeBSD is what I would recommend to anyone looking to switch off Linux desktops due to being a bit more user friendly and having way more packages than the others (FreeBSD+). Don't get me wrong I love the simplicity of OpenBSD with the default FVWM (I'm a sucker for Motif even all these years later) and use it for banking off a memory stick boot but don't know if I would recommend it as a daily driver. Still it is excellent for internet facing servers. Haven't used NetBSD much but was going to play around with it soon just for heck of it. If you cut your teeth on AIX, Solaris and HP-UX (hate HP but its still my favorite UNIX as its the most pure) POSIX is pretty much POSIX and none of them intimidate you. With Linux though its like seeing an old friend become a junkie (ie become Windows lite). All so Red Hat can steal other's work and cash in.

            1. asdf
              Facepalm

              Re: minor quibbles

              Oops forgot to mention DragonFly (among some others) which I also haven't played with much (other than pfSense and m0n0wall as routers are fun). DragonFly being based off an older version of FreeBSD its probably a bit less unique than some of the other BSDs but again POSIX is POSIX.

            2. This post has been deleted by its author

            3. MacroRodent

              Re: minor quibbles

              >All so Red Hat can steal other's work and cash in.

              That is quite uncalled-for. Whatever one thinks of Red Hat products, it still is one of the largest sponsors of open source software developers.

              1. asdf

                Re: minor quibbles

                >it still is one of the largest sponsors of open source software developers.

                Funny how more and more of those sponsorships are moving projects towards eventually being GNU/Linux only. You know the OS they make money off and are starting to basically own.

              2. W.O.Frobozz

                Re: minor quibbles

                "Sponsor" with a desire to steer the ship. They've been trying to since Redhat 5.0 and the early Gnome debacle.

          2. This post has been deleted by its author

            1. asdf

              another quibble

              Where OpenBSD can be flaky is on the 6 month upgrades if you stick with stable. Still way better than say Ubuntu but it does usually take some work but it well documented at least.

        2. Doctor Syntax Silver badge

          "come on over to *BSD and Lumina"

          Lumina I'm not sure of. Reading the designer's comments at http://blog.pcbsd.org/2014/04/quick-lumina-desktop-faq/ it looks as if he's in the "we'll decide what you put on your desktop" camp like Gnome & Unity. I'll stock to KDE.

          1. asdf

            >I'll stock to KDE.

            KDE is fine (can't believe I am saying that) because unlike Gnome, at least it hasn't decided that Linux only is an eventually design goal. I do worry about that changing perhaps in the future as the freedesktop borg rolls on which is partially why I switched from the default. Plus KDE is still a bit heavy for my taste. The only thing I don't like about Lumina really is no ability to type in a text box in the main menu to find stuff. Also in general I think its less about them deciding what I put on my desktop and more about limited options due to the project being rather new with not a lot of developer resources thrown at it compared to some of the heavyweights. I like where its going and it seems to fix the itches I have with fluxbox being its based on it (for now). We will see how it develops but again the whole edge to open source is choice that even systemd can't take away.

      4. W.O.Frobozz

        Look, a systemd astroturfer.

        (And yes I mean Astroturfer. It's funny how the systemd fanatics sound just like the Microsoft Munchkins.)

        1. asdf

          accusations of turfing are usually a last resort of fanbois

          Except the Microdrone turfers are almost always AC. Check my post history and see how many times I have tore into especially Microsoft. Used to be big on Linux but started using systemd, saw the direction RH and that putz Poettering was leading Linux and genuinely grew to hate the freedesktop borg for purely technical, philosophical and totally non financial reasons. In fact my employer would probably prefer I don't have an opinion one way or another.

    2. Paul Crawford Silver badge
      Joke

      Come on, they looked at the joys Windows users have with knowing what all those instances of svchost are actually doing and they thought "you know what, we want a bit of that action"

  3. tom dial Silver badge

    Demotion time?

    If Chromium is to download binaries for which free source is unavailable, it would seem reasonable to remove it from the main repository to non-free. It should be available for those of us who wish it, but easily excludable by those who are more picky about free software or object to what chromium might do.

    1. Voland's right hand Silver badge

      Re: Demotion time?

      It's half broken in jessie anyway. Hangouts extension does not work - crashes immediately. Other stuff is also broken.

      If it was any other package I would have bothered sending bugs (and patches). With Google spyware, no thanks, downloading a fresh up-to-date Firefox is a better option.

  4. streaky

    Disabling/Linux

    chmod 000? Nobody?

    On a more serious note I don't see how the chromium project backdooring people's PCs is Debian's fault regardless of it being their problem. Protip: even OSS distros rely on upstreams that are supposedly trustworthy not behaving in a nefarious manner; anybody who believes otherwise has serious grip on reality problems.

    1. asdf
      Mushroom

      Re: Disabling/Linux

      >OSS distros rely on upstreams that are supposedly trustworthy

      Until they find out they are not and then fork them like them should like the OpenBSD folks have done a much better job than Debian. Flame on.

      1. This post has been deleted by its author

        1. streaky

          Re: Disabling/Linux

          Forking Chromium as a Linux distro is a major investment of time and expertise that most can't afford.

  5. Christian Berger

    We need another rule for free software

    Software cannot be truly free if it's to complex. In order to participate in its development, software needs to be as simple as possible.

Page:

POST COMMENT House rules

Not a member of The Register? Create a new account here.

  • Enter your comment

  • Add an icon

Anonymous cowards cannot choose their icon

Other stories you might like