Tails 3.2 Anonymous OS to Work Better on Nvidia Maxwell GPUs, Add PPPoE Support

Tails, the amnesic incognito live system, also known as the Anonymous Live CD, will soon get a new version that promises to introduce several new features and updated components, along with an improved installer.

Pitivi 1.0 Release Candidate

• Pitivi 1.0 Release Candidate — “Ocean Big Chair”

  We’re proud to release the first Pitivi 1.0 release candidate “Ocean Big Chair” (0.99). This release has many bug fixes and performance improvements, and is a release candidate for 1.0. Our test suite grew considerably, from 164 to 191 meaningful unit tests. You can install it right away using Flatpak.

• Pitivi 1.0 Open-Source Linux Video Editor Is Up to RC State, Download as Flatpak

  Pitivi, the popular free and open-source video editor for GNU/Linux distributions, is about to hit the 1.0 milestone and become a stable software that's ready to use for some serious video editing tasks. More than nine months after the release of Pitivi 0.98 back in early December 2016, the development team has announced today that they've released the first RC (Release Candidate) milestone of the upcoming major Piviti 1.0 version, tagged as build 0.99 and dubbed "Ocean Big Chair."

• Pitivi 1.0 Release Candidate Arrives

  The Pitivi open-source non-linear video editor has been in development for thirteen years while its v1.0 release is finally near. Coming out this morning as a surprise is the Pitivi 1.0 release candidate, marked as Pitivi v0.99. The Pitivi 1.0 RC is primarily comprised of many bug fixes and performance improvements, thanks in part to more unit testing.

Graphics: RADV Vulkan vs. RadeonSI OpenGL, Open-Source OpenCL, VIA Graphics & Other Vintage GPUs

• RADV Vulkan vs. RadeonSI OpenGL Performance With Linux 4.13 + Mesa 17.3-dev

  It's been a few weeks since last delivering any large RADV/RadeonSI open-source AMD Linux graphics benchmark results due to being busy with testing other hardware as well as battling some regressions / stability problems within the AMDGPU DRM code and Mesa Git. But with Linux 4.13 stable and the newest Mesa 17.3-dev code, things are playing well so here are some fresh OpenGL vs. Vulkan benchmarks on three Radeon graphics cards.

• Open-Source OpenCL Adoption Is Sadly An Issue In 2017

  While most of the talks that take place at the annual X.Org Developers' Conference are around the exciting progress being made across the Linux graphics landscape, at XDC2017 taking place this week at Google, the open-source GPGPU / compute talk is rather the let down due to the less than desirable state of the open-source OpenCL ecosystem. Tom Stellard who formerly worked for AMD on their LLVM compiler stack and compute initiatives who recently joined Red Hat provided a "Current state of Open Source GPGPU" talk. It's not too much of a surprise if you are up-to-date in your daily Phoronix reading and our close coverage of all things Linux GPU. But if you're not a devoted reader or looking for an hour synopsis, check out his presentation embedded in this article.

• VIA Graphics & Other Vintage GPUs Still Interest At Least One Developer In 2017

  Kevin Brace, the sole active developer left working on the OpenChrome driver stack for VIA x86 graphics, presented yesterday at XDC2017 about his work on this driver and how in the years to come he still hopes to work on other vintage GPU support. Brace's work mostly covered his personal motivations, a brief history of Via Unichrome and the Linux driver options, and then his recent work on trying to get the OpenChrome DDX and DRM drivers into shape.

Security: Antipatterns in IoT Security, Signing Programs for Linux, and Guide to Two-Factor Authentication

• Antipatterns in IoT security

  Security for Internet of Things (IoT) devices is something of a hot topic over the last year or more. Marti Bolivar presented an overview of some of the antipatterns that are leading to the lack of security for these devices at a session at the 2017 Open Source Summit North America in Los Angeles. He also had some specific recommendations for IoT developers on how to think about these problems and where to turn for help in making security a part of the normal development process. A big portion of the talk was about antipatterns that he has seen—and even fallen prey to—in security engineering, he said. It was intended to help engineers develop more secure products on a schedule. It was not meant to be a detailed look at security technologies like cryptography, nor even a guide to what technical solutions to use. Instead, it targeted how to think about security with regard to developing IoT products.

• Signing programs for Linux

  At his 2017 Open Source Summit North America talk, Matthew Garrett looked at the state of cryptographic signing and verification of programs for Linux. Allowing policies that would restrict Linux from executing programs that are not signed would provide a measure of security for those systems, but there is work to be done to get there. Garrett started by talking about "binaries", but programs come in other forms (e.g. scripts) so any solution must look beyond simply binary executables. There are a few different reasons to sign programs. The first is to provide an indication of the provenance of a program; whoever controls the key actually did sign it at some point. So if something is signed by a Debian or Red Hat key, it is strong evidence that it came from those organizations (assuming the keys have been securely handled). A signed program might be given different privileges based on the trust you place in a particular organization, as well.

• A Guide to Common Types of Two-Factor Authentication on the Web

  Two-factor authentication (or 2FA) is one of the biggest-bang-for-your-buck ways to improve the security of your online accounts. Luckily, it's becoming much more common across the web. With often just a few clicks in a given account's settings, 2FA adds an extra layer of security to your online accounts on top of your password. In addition to requesting something you know to log in (in this case, your password), an account protected with 2FA will also request information from something you have (usually your phone or a special USB security key). Once you put in your password, you'll grab a code from a text or app on your phone or plug in your security key before you are allowed to log in. Some platforms call 2FA different things—Multi-Factor Authentication (MFA), Two Step Verification (2SV), or Login Approvals—but no matter the name, the idea is the same: Even if someone gets your password, they won't be able to access your accounts unless they also have your phone or security key. There are four main types of 2FA in common use by consumer websites, and it's useful to know the differences. Some sites offer only one option; other sites offer a few different options. We recommend checking twofactorauth.org to find out which sites support 2FA and how, and turning on 2FA for as many of your online accounts as possible. For more visual learners, this infographic from Access Now offers additional information. Finally, the extra layer of protection from 2FA doesn't mean you should use a weak password. Always make unique, strong passwords for each of your accounts, and then put 2FA on top of those for even better log-in security.