Heads Up!

Just a quick post to let you know that the LibreELEC logo branding will change. The current “branch” logo suited at the time of forking because it resonated with team members who type “git branch” on a daily basis; branching and forking have similar meaning to developers.

Since forking the LibreELEC team has absorbed people who are less development focussed and we started to look at how our logo is used. The leafy green shades of the branch look nice on the website masthead but aren’t so good in the settings add-on when contrasted against the graphics and backgrounds of the random skins people choose; notably the default ‘Estuary’ skin in LibreELEC 8.0 (Krypton) which needs a single colour logo.

It became clear we needed an icon logo more than an image logo. We also wanted something that looked professional, i.e. created in less haste and using a proper font, that we could do fun things with similar to how Kodi experiments with its ‘K’ logo.

In recent weeks the awesome Sam Fisher has been guiding us through the yes, no, no, no, maybe, yes, urgh, no, no, love-it! creative process of coming up with ideas, mock-ups and seeking the collective feedback of a team who aren’t shy with opinions. Sam, thank you for your efforts and patience!

In the end the team arrived at something both familiar and different. It will be revealed in LibreELEC 7.0.0 (Jarvis) and in a one-time exception to GitHub commit rules, changes will be merged after we publish 7.0.0 to avoid spoiling the surprise.

LibreELEC team 🙂

14 Responses

  1. KodiFan says:

    Maybe you could have different boot images like Kodi does for each version?
    Great job so far.. running on a Raspberry Pi 2 and love the clearly laid out plan.

  2. JJK9 says:

    Aww i was getting used to the leafy greens, hopefully version 7 gets released soon although thats more for the raspberry pi video fix than anticipation for the logo.

    • chewitt says:

      v6.95.2 will be available for manual update in a few hours. Kodi will prob. release 16.1 final over the weekend so under “Plan C” our 7.0.0 release should appear sometime next week. Fingers crossed.

  3. MayeulC says:

    Really looking forward to this. Cheers, and keep up the good work 🙂

  4. Matt says:

    Hey guys.
    Quick question – will do continuous upgrades without manual method ?
    Eg. Upgrading major versions?

    It’s hard for our customers to do the OpenELEC manual update method so hoping LibreELEC will be able to update between major versions from within KODI 🙂

    • chewitt says:

      Yes/No .. the issue with major version update is not LE or Kodi (which update fine) but users with lots of [unknown] addons installed. The more customised the install the greater the chance of something being incompatible. In future we plan to permit manual update from the GUI within the LE settings addon (which is technically no different to a copy/paste manual update) but fully automatic update is unlikely due to the risks posed by addons. We would *love* to auto-update major versions, but it would be a huge gamble.

  5. pd says:

    Please throw in the image you’re talking about. It’s just bloody annoying otherwise. That is, assuming uBlock hasn’t nabbed it.

  6. cOEu says:

    Thanks a lot for introducing HTTPS for your website. Could you please do the same for downloads or – if that’s not wanted or not possible (mirrors?) – add a list of installation image hashes* to the already-secure download overview page**? Thank you 🙂

    * preferably SHA256 or better
    ** please note that hashes retrieved via an insecure connection (HTTP) only help with checking for accidental corruption during download, i.e. they really need to be downloadable securely (e.g. listed on a secure page or provided in a separate securely-downloadable file containing) to be truly useful.

    • chewitt says:

      https for downloads is not possible as we’re using redirection software and a network of mirrors we have no control over. If you append ?mirrorlist to the download URL you’ll see a list of md5/sha1/sha256 hashes for the file. I’ll look at surfacing that on the website a better way so people can test for corrupted downloads.

  7. cOEu says:

    That’s nice, but as I mentioned, that (i.e. linking to ?mirrorlist) really isn’t enough. These hashes are only downloadable via HTTP, i.e. they can only be used for checking for accidental corruption. If anyone tampers with the images (malicious/hacked mirror, router, proxy, access point, computer on LAN via redirection, …), the attacker can simply change the transmitted hashes as well.

    Therefore, please provide a checksum file available via HTTPS (on libreelec.tv) or actually embed the hashes on the secure download page (i.e. currently https://libreelec.tv/download-temp/). I realize that this wasn’t available for OpenELEC either, but that’s no reason to not fix it now – especially since you’re doing spring cleaning right now 🙂

    If you’re wondering if such an attack is realistic: there have been reports of exit nodes on a certain three-letter network actively infecting downloaded software. I can’t see any reason why this couldn’t/shouldn’t also happen with *ELEC installation images (or updates, but that’s the next step …).

    • cOEu says:

      Small clarification: if the ?mirrorlist page with hashes is only generated by your server (and not on the mirrors), it obviously cannot be changed by the mirrors. This only helps in the “malicious mirror” case though and all the rest still holds.

      • chewitt says:

        Malicious mirror isn’t a case we can solve without spending a ton of money we don’t have on hosting our own mirror servers. Even if we did have the money I can list a dozen better things to spend it on. As files containing hashes that we can publish will reside on the same host as the potentially compromised files they validate they should not be considered trustworthy hash files. Similar case for any hashes we insert on our download pages. So, as we cannot provide all encompassing assurance against those hashes, and to avoid creating a false sense of security, we will only publish them to help users identify corrupted downloads, which TBH is not strictly necessary as a corrupted .tar or .img.gz file will either fail to decompress or will fail the embedded md5 validation in the update process. I’ve observed a number of Tor scenarios courtesy of my CERT/IR day-job but wrapping files in-transit with malware isn’t something we can defeat when 99%+ of users have no clue how to validate a hash (and if we publish a wiki article nobody will read it). The more serious “content inside the .tar file was modified in transit” scenario is of similar low concern because if you’re a target of interest to nation-state actors with the resources required for those attacks you have a world of problems we cannot solve (and your OpSec is flawed if you’re using LE for anything serious). In the end complexity vs. security will always be a balancing act. No matter what we do a subset of tin-foil-hat wearing users will be upset about our failure to take things as n’th level seriously as they do. We can only please some of the people some of the time.

  8. PatrickJB says:

    Good move, I was a bit concerned about the old Logo but the new was is great! It says to me, fun, freedom and lets not take this all too seriously! ;0)

    Good luck with the project, I’ll be following K’s community builds.