Home Tags GNU

Tag: GNU

Ars spends too much time trying to work in Haiku, the...

After years of alpha, the open-source execution of BeOS is beautiful but buggy.

GCC GNU compiler adds C++ 17 support

With the 7.1 version of the GCC (GNU Compiler Collection), released this week, the platform gets early support for the C++ 17 standard and diagnostics enhancements.Version 7.1 has a C++ front end with experimental support for all of the the C++ 17 d...

802.eleventy what? A deep dive into why Wi-Fi kind of sucks

The good news is that it doesn't have to suck, if you build it out properly.

JSA10774 – 2017-01 Security Bulletin: Network and Security Manager (NSM): Multiple...

CVE CVSS base score Summary CVE-2015-5600 6.5 (CVSS:3.0/AV:N/AC:L/PR:N/UI:N/S:U/C:L/I:N/A:L) The kbdint_next_device function in auth2-chall.c in sshd in OpenSSH through 6.9 does not properly restrict the processing of keyboard-interactive devices withi...

Code Reuse a Peril for Secure Software Development

The amount of insecure software tied to reused third-party libraries and lingering in applications long after patches have been deployed is staggering. It’s a habitual problem perpetuated by developers failing to vet third-party code for vulnerabilities, and some repositories taking a hands-off approach with the code they host. This scenario allows attackers to target one overlooked component flaw used in millions of applications instead of focusing on a single application security vulnerability. The real-world consequences have been demonstrated in the past few years with the Heartbleed vulnerability in OpenSSL, Shellshock in GNU Bash, and a deserialization vulnerability exploited in a recent high-profile attack against the San Francisco Municipal Transportation Agency. These are three instances where developers reuse libraries and frameworks that contain unpatched flaws in production applications. Related Posts Adobe Patches Flash Zero Day Under Attack October 26, 2016 , 11:24 am Dyn Confirms DDoS Attack Affecting Twitter, Github, Many Others October 21, 2016 , 10:01 am Threatpost News Wrap, June 17, 2016 June 17, 2016 , 11:15 am Security researchers at Veracode estimate that 97 percent of Java applications it tested included at least one component with at least one known software vulnerability. “The problem isn’t limited to Java and isn’t just tied to obscure projects,” said Tim Jarrett senior director of security, Veracode. “Pick your programming language.” Gartner, meanwhile, estimates that by 2020, 99 percent of vulnerabilities exploited will be ones known by security and IT professionals for at least one year. Code Reuse Saves Time, Invites Bugs According to security experts, the problem is two-fold. On one hand, developers use reliable code that at a later date is found to have a vulnerability. Second, insecure code is used by a developer who doesn’t exercise due diligence on the software libraries used in their project. “They’ve heard the warnings and know the dangers, but for many developers open source and third-party components can be a double-edge sword – saving time but opening the door to bugs,” said Derek Weeks, vice president and DevOps advocate at Sonatype. In an analysis of 25,000 applications, Sonatype found that seven percent of components had at least one security defect tied to the use of an insecure software component. Repositories GitHub, Bitbucket, Python Package Index and NuGet Gallery are essential tools helping developers find pre-existing code that adds functionality for their software projects without having to reinvent the wheel. Java application developers, for example, rely on pre-existing frameworks to handle encryption, visual elements and libraries for handling data. “Software is no longer written from scratch,” Weeks said. “No matter how new and unique the application, 80 percent of the code used in a software application relies on third-party libraries or components.” He said enterprises are more reliant on the software supply chain than ever before. But he says many of the go-to open-source repositories that make up that supply chain are not vetted libraries of reliable code. Rather, they are warehouses with a varying percentage of outdated projects with security issues. According to an analysis of Sonatype’s own Central Repository in 2015, developers had made 31 billion download requests of open source and third-party software components, compared to 17 billion requests the year before. And when Sonatype analyzed its own code library, it found 6.1 percent of code downloaded from its Central Repository had a known security defect. Weeks says Sonatype’s is doing better than other repositories that offer no tools, no guidance and no red flags to prevent developers from using frameworks with faulty code. “There is no Good Housekeeping Seal of Approval for third-party code.” “Faulty code can easily spawn more problems down the road for developers,” said Stephen Breen, a principal consultant at NTT Com Security. “Even when development teams have the best intentions, it’s easy for developers working under tight deadlines to not properly vet the third-party code used in their software.” Breen said when insecure code is unknowingly used to build a component within a software program, problems snowball when that component is used inside other larger components. One example of vulnerable third-party code reused repeatedly is a deserialization flaw in Apache Commons Collections (commons-collections-3.2.1.jar) – first reported in 2015 and patched in November of the same year. Source: Veracode Breen found there are still 1,300 instances of the old vulnerable version of the Commons Collections lurking inside Java applications using Spring and Hibernate libraries and hosted across multiple open source code repositories. “The developer knows they are picking Spring or Hibernate for their development project. They don’t take it to the next level and realize they are also getting Common Collections,” Breen said. “That Common Collections library is then used by thousands more projects.” According to Veracode, Apache Commons Collections is the sixth-most common component used in Java applications. It found that the unpatched versions of the software was in 25 percent of 300,000 Java applications scanned. Even more challenging for developers is updating those applications that are using the vulnerable version of libraries and frameworks since flaws were patched. “Think of it like a faulty airbag. Carmakers used those faulty airbags in millions of vehicles. Now it’s the carmaker on the hook to fix the problem, not the airbag maker,” Weeks said. Leaky Apps, Bad Crypto, Injection Flaws Galore Veracode said the Apache Common Collection example is the tip of the iceberg. When Veracode examined vulnerabilities tied to insecure code it found application information leakage, where user or application data can be leveraged by an attacker, is the most prevalent type of vulnerability, accounting for 72 percent of third-party code flaws. Second are cryptographic issues representing 65 percent of vulnerabilities. That was followed by Carriage Return Line Feed (CRLF) injection flaws and cross site scripting bugs. Source: Veracode Compounding the problem is an increased dependency on open-source components used in a wide variety of software products. The federal government is typical. It has an open-source-first policy as do many private companies. Relying on third-party libraries shortens development time and can improve the safety and quality of their software projects, Weeks said. “Not only does code reuse save time but it also allows developers to be more innovative as they focus on creating new functionality and not writing encryption libraries from scratch,” Weeks said. Done correctly, code reuse is a developer’s godsend, he said. For those reasons, security experts say it’s time for the industry to stop and consider where code originates. Sonatype, which markets and sells code verification services, promotes the idea of documenting software’s supply chain with what it calls a “software bill of materials.” That way developers can better scrutinize open-source frameworks before and after they are used; making it easier to update those applications that are using vulnerable old versions of libraries. Sonatype said it found one in 16 components it analyzed had a vulnerability that was previously documented, verified and with additional information available on the Internet. “I can’t imagine any other industry where it’s okay that one in 16 parts have known defects.” The problem is that among developers there is a mix of denial and ignorance at play. “Developers choose component parts, not security,” Weeks said. It should be the other way around. “If we are aware of malicious or bad libraries or code, of course we want to warn our users,” said Logan Abbott, president of SourceForge, a software and code repository. “We scan binaries for vulnerabilities, but we don’t police any of the code we host.” Repositories Say: ‘We’re Just the Host’ Repositories contacted by Threatpost say their platforms are a resource for developers akin to cloud storage services that allow people to store and share content publicly or privately. They don’t tell users what they can and cannot host with their service. They say rooting out bugs in software should be on shoulders of developers – not repositories. Writing good vulnerability-free code starts at getting good code from healthy repositories with engaged users. “We think of ourselves as the Home Depot of repositories,” said Rahul Chhabria, product manager for Atlassian Bitbucket. “We provide the tools, material and platform to get the job done right.” Chhabria said Bitbucket offers a range of tools to help sniff out bad or insecure components such as the third-party tool SourceClear for scanning dependency chains. It also offers Bitbucket Pipelines that allows for cloud-based team development of software projects and simplifies peer review. GitHub is one of the largest repositories; it hosts 49 million public and private projects for its 18 million users. It does not scan or red flag insecure code hosted on its platform, according to Shawn Davenport, VP of security at GitHub. Instead developers can use third party-tools such as Gemnasium, Brakeman and Code Climate for static and dependency analysis. “There is a lot of hidden risk out there in projects,” Davenport said. “We do our best to make sure our developers know what tools are available to them to vet their own code.” He estimates a minority GitHub developers take advantage of software scanning and auditing tools. “Unfortunately security isn’t a developers first priority.” Other repositories told Threatpost they intentionally take a hands-off approach and say expecting them to police their own software isn’t feasible, not part of their mission and nothing they plan to do. They point out, flawed or not, developers want access to all code – even older components. “An implementation of a library in one framework might not be a security risk at all,” Breen said. He points out developers often temporarily revert to those old libraries as stopgaps should an updated version break a project. Automated Scanning to the Rescue? One attempt at nipping the problem at the bud is the used of automated security vulnerability and configuration scanning for open source components. By 2019, more than 70 percent of enterprise DevOps initiatives will incorporate automated scanning, according to Gartner. Today only 10 percent of packages are scanned. The Node.js Foundation, an industry consortium designed to promote the Node.js platform, relies on a more community-based approach via the Node.js Security Project. The goal is to provide developers a process for discovering and disclosing security vulnerabilities found in the Node.js module ecosystem. According to Node.js the approach is a hybrid solution that consists of a database of vulnerabilities and a community communication channel for vetting and disclosing vulnerable code. “It’s not a story about security professionals solving the problem, it’s about how we empower development with the right information about the (software) parts they are consuming,” Weeks said. “In this case, the heart of the solution lies with development, and therefore requires a new approach and different thinking.”

BaySand, Codasip, Codeplay and UltraSoC accelerate IoT development with “silicon-to-intelligence” RISC-V...

MOUNTAIN VIEW, CA, 29th November 2016: BaySand, Codasip, Codeplay and UltraSoC today announced an integrated IoT development platform based on the RISC-V open processor instruction set architecture (ISA).

The platform offers an open-standards-based solution that allows designers of systems-on-a-chip (SoCs) for IoT applications to get from concept to silicon with a high level of software integration in record time and substantially de-risks the entire product development process.This new collaboration will be formally announced at the 5th RISC-V Workshop (Google Quad Campus, Mountain View, CA, 29th November), and combines the following partnership: - BaySand’s foundational IP and Metal Configurable Standard Cell (MCSC) technology- Codasip’s extensible Codix Bk RISC-V-compliant processor implementation- Codeplay’s ComputeSuite software development tools for open standards middleware, and- UltraSoC’s on-chip debug and analytics architecture The result is an end-to-end development flow that supports the rapid evolution of IoT systems, enabling timely market entry, in-market feature enhancement and on-going usability and cost optimization, all at the price points demanded in this highly cost-sensitive market. “RISC-V adoption is accelerating, and the IoT is clearly an arena where an open, independent processor architecture offers very powerful advantages,” said Caroline Gabriel, Research Director of ReThink Research. “But as with any processor architecture, the RISC-V ISA needs a healthy, co-operative ecosystem surrounding it: an ecosystem that puts designers in control and empowers innovation.” Rick O’Connor, Executive Director of the RISC-V Foundation, commented: “A key part of our mission at the RISC-V Foundation is to bring technology developers together, in a standards-based environment, to build a robust ecosystem around the RISC-V ISA. We’re delighted to see these four leading firms in the RISC-V community coming together to offer such a powerful solution.” The new platform leverages BaySand’s patented MCSC technology which delivers the power, performance and density advantages of standard cell ASIC technology while reducing NRE and time to market (TTM) and dramatically increasing design flexibility.

The company’s UltraShuttle multi project wafers (MPW) and MetalCopy FPGA porting technology help to bring new designs to market quickly, with low risk: they combine with a proven and predictable design flow and a rich IP library to create an ideal solution for IoT class designs. At the IP level, Codasip’s Codix-Bk IP cores are the industry’s first commercially available RISC-V compliant processors, and are at the heart of the new joint platform offering.

They are available in multiple configurations and can be quickly and easily customized to the exact needs of IoT designs via unique application analysis technology and a model-based IP structure. UltraSoC contributes silicon IP and software tools that enable secure, non-intrusive monitoring and analysis of IoT device behavior.

These powerful features ease the task of writing and debugging the software that is intrinsic to the operation of complex ICs; they accelerate first-time bring up of new devices; and the same IP allows robust hardware-based security features that can detect unexpected behavior caused by bugs or by malicious interference (Bare Metal Security™). At the highest level within the new platform, Codeplay provides developers with an open standards based programming model that extends from device-specific functionalities all the way up to highly abstracted machine learning paradigms such as Google’s TensorFlow.

ComputeSuite extends the RISC-V platform with OpenCL™ and SYCL™ allowing applications to target the underlying hardware for highest performance, using standard APIs. Partner quotesRupert Baines, CEO, UltraSoC: “We’re delighted to be coming together with three of the other key players in the RISC-V arena, BaySand, Codasip and Codeplay. Our aim in this collaboration is to enable accelerated product development cycles, lower costs and more agile development, in particular for IoT designs. Our technology helps SoC developers across the chip and throughout the development flow, and this partnership reinforces the strength of that offering.” Karel Masarik, CEO, Codasip: “This collaboration is an important one for our customers as they look to replace proprietary ISA’s with RISC-V.
It allows them to quickly bring new SoCs to life, while providing functionality that exceeds what they have had access to in the past. Our Codix-Bk series of RISC-V processor IP, with its LLVM-based development environment, make integration quick and low risk, demonstrating the power of commitment to open standards.” Ehud (Udi) Yuhjtman, EVP marketing and Sales at BaySand: “BaySand is a supporter of open source hardware and we are excited to be part of this great team that brings together an open source ISA complete solution.

This RISC-V implementation with the UltraSOC tools is a game changer that will enable designers and companies to design at an affordable budget their own efficient IoT ASIC and system. We are working on the ASIC implementation which will be available for evaluation to our customers and partners.

The complete solution and technology provides the ability to build custom designs with BaySand special UltraShuttle MPW and the Metal Configurable Standard Cell (MCSC)”. Andrew Richards, CEO, Codeplay: “Codeplay is excited to see RISC-V gaining in popularity and we are keen to ensure software developers are correctly equipped to host their software applications on it.

Codeplay is working extensively with machine learning solutions such as Google with TensorFlow, and we will bridge the gap on RISC-V with the open standards OpenCL and SYCL.” About UltraSoCUltraSoC is an independent provider of SoC infrastructure that enables rapid development of embedded systems based on advanced SoC devices.

The company is headquartered in Cambridge, United Kingdom.

For more information visit www.ultrasoc.com. About BaysandBaySand is the leader in application configurable ASICs targeting short time-to-market and cost-effective ASIC solutions. With its unique and patented Metal Configurable Standard Cell (MCSC) technology and Field Configurable DSP (fcDSP) architecture, the company provides ASIC designers with world-class solutions featuring low non-recurring engineering costs, short time-to-market, low power, low unit cost, high performance, programmability and flexibility.

BaySand is fabless, privately held and based in the Silicon Valley, San Jose CA.

For further information about BaySand, visit http://www.baysand.com. About CodeplayCodeplay is internationally recognized for expertise in open standards for heterogeneous systems and has many years of experience in the development of Compilers, Runtimes, Debuggers, Test Systems, and other specialized tools.

Codeplay has delivered standards-compliant systems for some of the largest semiconductor companies in the world, focusing specifically on high-performance heterogeneous processor solutions for CPUs, GPUs, DSPs, FPGAs and specialized imaging and vision processors.
Visit www.codeplay.com for more information. About CodasipCodasip delivers leading-edge processor IP technology that provides the advantages of industry standard processor IP with the ability to optimize for your unique application.

Codasip’s unique model-based processor IP, and application analysis technology, makes processor customization and optimization available to any design team.

As a founding member of the RISC-V foundation (riscv.org) and long term supplier of LLVM and GNU based processor solutions Codasip is committed to open standards for embedded processors.

Formed in 2006 and headquartered in Brno, Czech Republic, Codasip currently has offices in the US and Europe. More information on Codasip’s products and services is available at http://www.codasip.com. ContactsUltraSoCAndy Gothard:andy.gothard@ultrasoc.com+44 7768 082 044Twitter: @ultrasoc CodeplayCharles Macfarlanecharles.macfarlane@codeplay.com+44 7766 104856Twitter: @codeplaysoft CodasipNeil Handhand@codasip.com+1 650 353 7486Twitter: @codasip BaysandJoshua GJoshua@baysand.com

Cryptsetup Vulnerability Grants Root Shell Access on Some Linux Systems

A vulnerability in cryptsetup, a utility used to set up encrypted filesystems on Linux distributions, could allow an attacker to retrieve a root rescue shell on some systems. From there, an attacker could have the ability to copy, modify, or destroy a hard disk, or use the network to exfiltrate data. Cryptsetup, a utility used to setup disk encryption based on the dm-crypt kernel module, is usually deployed in Debian and Ubuntu. Researchers warned late last week that if anyone uses the tool to encrypt system partitions for the operating systems, they’re likely vulnerable. Two researchers, Hector Marco of the University of the West of Scotland and Ismael Ripoll, of the Polytechnic University of Valencia, in Spain, disclosed the vulnerability on Friday at DeepSec, a security conference held at the Imperial Riding School Renaissance Vienna Hotel in Austria. According to the researchers, the script with the vulnerability (CVE-2016-4484) is in the Debian cryptsetup package 2:1.7.2-3 and earlier. Systems that use Dracut, an infrastructure commonly deployed on Fedora in lieu of initramfs – a simple RAM file system directory, are also vulnerable, according to the researchers. The pair say additional Linux distributions outside of Debian and Ubuntu may be vulnerable, they just haven’t tested them yet. The problem stems from the incorrect handling of a password check when a partition is ciphered with LUKS, or Linux Unified Key Setup, a disk encryption specification that’s standard for Linux. Assuming an attacker has access to the computer’s console, when presented with the LUKS password prompt, they could exploit the vulnerability simply by pressing ‘Enter’ over and over again until a shell appears. The researchers say the exploit could take as few as 70 seconds. After a user exceeds the maximum number of three password tries, the boot sequence continues normally. Another script in the utility doesn’t realize this, and drops a BusyBox shell. After carrying out the exploit, the attacker could obtain a root initramfs, or rescue shell. Since the shell can be executed in the initrd, or initial ram disk, environment, it can lead to a handful of scary outcomes, including elevation of privilege, information disclosure, or denial of service. The researchers warn that the vulnerability is especially dangerous in public situations. “This vulnerability is specially serious in environments like libraries, ATMs, airport machines, labs, etc, where the whole boot process is protect (password in BIOS and GRUB) and we only have a keyboard or/and a mouse,” the vulnerability disclosure reads. All an attacker would need in those instances – assuming the system is running Linux – would be access to the keyboard or mouse, Marco and Ripoll say. Tourist information kiosks or airport check in kiosks could be prime targets, the two write. While an attacker would have to have physical access to carry out the attack in most instances, the two warn that in some cloud environments, like those deployed by Ubuntu, the vulnerability could be exploited without physical access. Users can remedy the vulnerability by fixing the cryptroot script file – /scripts/local-top/cryptroot – directly, suspending execution forever, according to the researchers. It’s unclear when a true fix will make its way to the Linux distributions. Neither Debian or Ubuntu immediately returned a request for comment on the vulnerability Tuesday. Marco and Ripoll claim they reported the issue to Debian two weeks ago and while the distribution fixed it, the researchers claim they don’t fully agree with the way it did it. “This is just one of the problems that the boot sequence has in GNU/Linux. It is too permissive on errors, that is. There is the general idea that if the user has physical access to the computer, then the user IS THE OWNER of the computer (this dates from the very beginning of computing). The IoT will dramatically change this assumption,” Marco and Ripoll told Threatpost. “When Windows detects an error… it just shows the blue screen… which is very bad if you are a developer but it is the best solution for 99.9% of the users. Shall the system be developer/hacker friendly, or user secure?”

RHBA-2016:2724-1: new packages: devtoolset-6

New devtoolset-6 packages are now available as a part of Red Hat DeveloperToolset 6.0 for Red Hat Enterprise Linux. Red Hat Developer Toolset is a Red Hat offering for developers on the Red HatEnterprise Linux platform that provides current versions of the GNU CompilerCollection (GCC), GNU Debugger (GDB), and other development, debugging, andperformance monitoring tools.

The devtoolset-6 package is the main meta packageof the devtoolset-6 Software Collection and installs other Red Hat DeveloperToolset 6.0 packages as dependencies.This enhancement update adds the devtoolset-6 packages to Red Hat DeveloperToolset. (BZ#1356527)For detailed changes, see the Red Hat Developer Toolset 6.0 User Guide linkedfrom the References section.All users who require devtoolset-6 are advised to install these new packages. Before applying this update, make sure all previously released erratarelevant to your system have been applied.For details on how to apply this update, refer to:https://access.redhat.com/articles/11258Red Hat Software Collections 1 for RHEL 6 SRPMS: devtoolset-6-6.0-6.el6.src.rpm     MD5: 9b98de364d9093132af390f2f8f7eeccSHA-256: 359f495f62148c3c93a3d2aa0539e64568cfdfee8b24963d8c66d3fce729bc03   x86_64: devtoolset-6-6.0-6.el6.x86_64.rpm     MD5: 3a9d7505590a95c7d0f0ef2e0a88b526SHA-256: 4397df64e94d1f76bdf152665442b472632716bebea618e0252a3f41b89afe15 devtoolset-6-build-6.0-6.el6.x86_64.rpm     MD5: f7bf0614203694e56c5bb4c27dca8b4cSHA-256: fc20fdcfc60603efd8f22413410dd96fadcce7539f3de81e0e434284dff0ed03 devtoolset-6-perftools-6.0-6.el6.x86_64.rpm     MD5: 212da40d1ba33ef0a9165fbe84a87a0fSHA-256: db4b56b07c030b776f1dc95230e9e8fd521731e198aa0b3777183b9a85a68bec devtoolset-6-runtime-6.0-6.el6.x86_64.rpm     MD5: 00a9f17dfb95bd214d46ca52ca93b2f3SHA-256: 4cac59e2c32d34f7c9b63df073cbd6f4e87f4d6eed62eed9febee60d7fbbf31d devtoolset-6-toolchain-6.0-6.el6.x86_64.rpm     MD5: dcdee89072ed0f38b580527e82e6cbb8SHA-256: 3ff11793b498b6a4cfdedaef1503fdcbbaf85cc4e0323c1a082a6e1bfae7f45d   Red Hat Software Collections 1 for RHEL 7 SRPMS: devtoolset-6-6.0-6.el7.src.rpm     MD5: 980a05a14bf7be6d0f092742f72c2ac8SHA-256: 6a4029aba90aa7bb10a78a3d942de3d25c0857e072bb776b407b071bdd2c6496   x86_64: devtoolset-6-6.0-6.el7.x86_64.rpm     MD5: 3ac0521f9557ca1106ce05c9f2d2ad95SHA-256: 932dd0ee060d2875fd14da4055ab34d159af75bece4287082ad38e688013b931 devtoolset-6-build-6.0-6.el7.x86_64.rpm     MD5: 476378dd42c06e4be5585c2f8165b7f8SHA-256: a28121f538fb26dd008ef9cffcb58c91208ceaa829c12443df7a408a1fdbf86b devtoolset-6-dockerfiles-6.0-6.el7.x86_64.rpm     MD5: 802a23c6cfefd91df6ae37158c76146eSHA-256: b300bbaba8429543aa90619141a2cfc1b9977be8a8d857effc93ca60978d18a5 devtoolset-6-perftools-6.0-6.el7.x86_64.rpm     MD5: b9c2cf6b78d02bdcba99fae8378d30aeSHA-256: 158f1eb8fb019eb1de813a840f433d8c1ec3323a034b5952bf79e90d820872a8 devtoolset-6-runtime-6.0-6.el7.x86_64.rpm     MD5: 72b584acea8ebf0ea723d296d43bc7b8SHA-256: c2fc6cacc5f503ebdd694fdc9136b8811a1e605c6ee11a3dfb6ee1fbaecb995a devtoolset-6-toolchain-6.0-6.el7.x86_64.rpm     MD5: 3081d00b37ee64ebe110cdb76c794e02SHA-256: 8535dcd27496b105dd4ed59cb868b7a7be128c4bf23fbf816b467f590c309278   (The unlinked packages above are only available from the Red Hat Network) 1356527 - devtoolset-meta refresh for DTS 6.0 [RHEL 6 / 7]1362204 - Change DTS dockerfiles to match those used to build docker registry images1367352 - Many DTS-4 references in DTS-6 Dockerfiles These packages are GPG signed by Red Hat for security. Our key and details on how to verify the signature are available from:

RHBA-2016:2721-1: new packages: devtoolset-6-binutils

New devtoolset-6-binutils packages are now available as a part of Red HatDeveloper Toolset 6.0 for Red Hat Enterprise Linux. Binutils is a collection of binary utilities, including ar (for creating,modifying, and extracting from archives), as (a family of GNU assemblers), gprof(for displaying call graph profile data), ld (the GNU linker), nm (for listingsymbols from object files), objcopy (for copying and translating object files),objdump (for displaying information from object files), ranlib (for generatingan index for the contents of an archive), readelf (for displaying detailedinformation about binary files), size (for listing the section sizes of anobject or archive file), strings (for listing printable strings from files),strip (for discarding symbols), and addr2line (for converting addresses to fileand line).

The devtoolset-6-binutils packages provide the Red Hat DeveloperToolset version of binutils.This enhancement update adds the devtoolset-6-binutils packages to Red HatDeveloper Toolset. (BZ#1356661)For detailed changes, see the Red Hat Developer Toolset 6.0 User Guide linkedfrom the References section.All users who require devtoolset-6-binutils are advised to install these newpackages. Before applying this update, make sure all previously released erratarelevant to your system have been applied.For details on how to apply this update, refer to:https://access.redhat.com/articles/11258Red Hat Software Collections 1 for RHEL 6 SRPMS: devtoolset-6-binutils-2.27-8.el6.src.rpm     MD5: 4aa3caf226ae52bafe81c8b55b46a48dSHA-256: 68a389ab71ae1ec8a7f7b3b9bc79555bab63f2427becbcc6d98800e9c3760544   x86_64: devtoolset-6-binutils-2.27-8.el6.x86_64.rpm     MD5: 587643d2fad17b87d5a9aa7870d08fb5SHA-256: daeede3c14ad4b28e11ceb0d0d162955a4f3d48488eef6fce53e5a27b25e6c8e devtoolset-6-binutils-debuginfo-2.27-8.el6.i686.rpm     MD5: de94586021e95ee7176e4427d612157bSHA-256: 6d7930ff3a53d9cb74251c730954ed5bf65dcdad4fc7c1bf12f55c46ee8da5e3 devtoolset-6-binutils-debuginfo-2.27-8.el6.x86_64.rpm     MD5: e8f9864e6c261a81e321f0661b00bcd7SHA-256: b94861b67be6722aefbdf613bda85ffc92a63c6d4463702b5a0986050bd79696 devtoolset-6-binutils-devel-2.27-8.el6.i686.rpm     MD5: 8f0677484935f600466f4253f1f95957SHA-256: dc00e2bd08e07fc0720f55ca33153e0dfaac56db254187199e4664bfeae943c5 devtoolset-6-binutils-devel-2.27-8.el6.x86_64.rpm     MD5: 5edd96220cf567dbd1aabbd849621522SHA-256: 9392431026e35283081fbcf93dd2a75f21fa738b390335fafc5a000f3efa8ae1   Red Hat Software Collections 1 for RHEL 7 SRPMS: devtoolset-6-binutils-2.27-10.el7.src.rpm     MD5: c1a4852f3fd062aa38ce03ba901b6304SHA-256: 1a1e3d529d05aba5097e2790eb21afd2e7ced8ee60117c62f5fe5574911a997b   x86_64: devtoolset-6-binutils-2.27-10.el7.x86_64.rpm     MD5: d30a23052ade27cfd3ae7c9f222b2b04SHA-256: 0b5bf9bf2ac0b880484b685f842e1b5c42fee113c5eeac519d2b86f398b0ec95 devtoolset-6-binutils-debuginfo-2.27-10.el7.i686.rpm     MD5: 30f6e7242a91acc2f070f659104bc04eSHA-256: af41f9f2add98278f574d9a8b8c29c59ce2835eea5d91b8de3907b0cf6f77e08 devtoolset-6-binutils-debuginfo-2.27-10.el7.x86_64.rpm     MD5: 846d9933f5543f98f1c38aa502cc637aSHA-256: 04b041669c3d9149dfca4039d501f9f70ebdd6dc27d7ad9b63c4116b77a909b7 devtoolset-6-binutils-devel-2.27-10.el7.i686.rpm     MD5: ca8b63d1ce3dd8ed4d456a07d44e3eaeSHA-256: ad5f5657fd6e6dc8724031884efa1fb72aa533d4fb8acdae09a5169f7a259ded devtoolset-6-binutils-devel-2.27-10.el7.x86_64.rpm     MD5: b6379343a7a80b71e1f230e6b10b369aSHA-256: 83d16eeb812e7328a69b6b1aa0d8803a20804f7f08a40f863187f89cbfe540fa   (The unlinked packages above are only available from the Red Hat Network) 1356661 - Need to rebase the binutils for DTS 61366145 - dwz applied to a dts-compiled binary complains about section offsets not monotonically increasing These packages are GPG signed by Red Hat for security. Our key and details on how to verify the signature are available from:

RHBA-2016:2681-1: tar bug fix update

Updated tar packages that fix one bug are now available for Red Hat EnterpriseLinux 7.2 Extended Update Support. The GNU tar program can save multiple files in an archive and restore files froman archive.This update fixes the following bug:* Previously, using the tar command with the --selinux option failed, as the tarutility freed memory incorrectly. With this update, the memory is freedcorrectly, and tar works as expected with the --selinux option. (BZ#1365645)Users of tar are advised to upgrade to these updated packages, which fix thisbug. Before applying this update, make sure all previously released erratarelevant to your system have been applied.For details on how to apply this update, refer to:https://access.redhat.com/articles/11258Red Hat Enterprise Linux HPC Node EUS (v. 7.2) SRPMS: tar-1.26-30.el7_2.src.rpm     MD5: 1beee0fb547923b3676c8ce144f77891SHA-256: 3972a1bffeca309e16e6e018a2ed515e8505b6d462304db0839bb1262eef7108   x86_64: tar-1.26-30.el7_2.x86_64.rpm     MD5: 5e9e3d311e349843ead77fb327ba59beSHA-256: 44faed22afbb146a4f0ab3780e163fec742edf3d2080adfd816abcbd27cc7cea tar-debuginfo-1.26-30.el7_2.x86_64.rpm     MD5: 2f1368f7d02cdcd8367a9b9479f47f1dSHA-256: a979962924e270531c9961e3b996f5072d770712b1b477c35b0454c25a19a971   Red Hat Enterprise Linux Server AUS (v. 7.2) SRPMS: tar-1.26-30.el7_2.src.rpm     MD5: 1beee0fb547923b3676c8ce144f77891SHA-256: 3972a1bffeca309e16e6e018a2ed515e8505b6d462304db0839bb1262eef7108   x86_64: tar-1.26-30.el7_2.x86_64.rpm     MD5: 5e9e3d311e349843ead77fb327ba59beSHA-256: 44faed22afbb146a4f0ab3780e163fec742edf3d2080adfd816abcbd27cc7cea tar-debuginfo-1.26-30.el7_2.x86_64.rpm     MD5: 2f1368f7d02cdcd8367a9b9479f47f1dSHA-256: a979962924e270531c9961e3b996f5072d770712b1b477c35b0454c25a19a971   Red Hat Enterprise Linux Server EUS (v. 7.2) SRPMS: tar-1.26-30.el7_2.src.rpm     MD5: 1beee0fb547923b3676c8ce144f77891SHA-256: 3972a1bffeca309e16e6e018a2ed515e8505b6d462304db0839bb1262eef7108   PPC: tar-1.26-30.el7_2.ppc64.rpm     MD5: 525961e92fdd9105d970d94a3567bb40SHA-256: 3174aa69eabfb5a0d9ca6a99487901e25fa682ff2e9aa2c345267b0d7c92e7dd tar-debuginfo-1.26-30.el7_2.ppc64.rpm     MD5: 7356247423638d354b8256307cff6e79SHA-256: ee4c88fb23e23965e32944ed0830e95ec1aed704abf91e59f149f78b9cdec3ad   PPC64LE: tar-1.26-30.el7_2.ppc64le.rpm     MD5: 1011691aafffe73e40e0cd44d0451c52SHA-256: 3810b1ed8b654571c0021773d05d2334cdffb8bdf4687c3b6dca0d23fbebc82b tar-debuginfo-1.26-30.el7_2.ppc64le.rpm     MD5: 81a3bdff851394c03a956637841ec032SHA-256: 52ed383d424a4bdfb5bc92a91df4c5ad250d58533c665cf6e701adea882793a4   s390x: tar-1.26-30.el7_2.s390x.rpm     MD5: 92d0832df02deb677ec662abe7ebe5e0SHA-256: c17f1deb849b90ba1557eb6bd272ece5cb904e4b138e316e38f3b35c29e90790 tar-debuginfo-1.26-30.el7_2.s390x.rpm     MD5: 9473a8e7e90296a142f0fd35deb8b7a5SHA-256: 659d42267f901208e4760d1686d2be5e888a6bc539e6f9b8bd99dd53ffa82de1   x86_64: tar-1.26-30.el7_2.x86_64.rpm     MD5: 5e9e3d311e349843ead77fb327ba59beSHA-256: 44faed22afbb146a4f0ab3780e163fec742edf3d2080adfd816abcbd27cc7cea tar-debuginfo-1.26-30.el7_2.x86_64.rpm     MD5: 2f1368f7d02cdcd8367a9b9479f47f1dSHA-256: a979962924e270531c9961e3b996f5072d770712b1b477c35b0454c25a19a971   Red Hat Enterprise Linux Server TUS (v. 7.2) SRPMS: tar-1.26-30.el7_2.src.rpm     MD5: 1beee0fb547923b3676c8ce144f77891SHA-256: 3972a1bffeca309e16e6e018a2ed515e8505b6d462304db0839bb1262eef7108   x86_64: tar-1.26-30.el7_2.x86_64.rpm     MD5: 5e9e3d311e349843ead77fb327ba59beSHA-256: 44faed22afbb146a4f0ab3780e163fec742edf3d2080adfd816abcbd27cc7cea tar-debuginfo-1.26-30.el7_2.x86_64.rpm     MD5: 2f1368f7d02cdcd8367a9b9479f47f1dSHA-256: a979962924e270531c9961e3b996f5072d770712b1b477c35b0454c25a19a971   (The unlinked packages above are only available from the Red Hat Network) These packages are GPG signed by Red Hat for security. Our key and details on how to verify the signature are available from:

VU#243144: Linux kernel memory subsystem copy on write mechanism contains a...

Linux kernel memory subsystem copy on write mechanism contains a race condition vulnerability Original Release date: 21 Oct 2016 | Last revised: 24 Oct 2016 Overview The Linux kernel since version 2.6.22 contains a race condition in the way the copy ...

GPG Sync simplifies encryption key management

In all the discussion about using encryption, a critical point keeps getting lost: It's difficult to work with, and it's even harder to deploy it at scale. Nowhere is the challenge more evident than in sending secure email. There are many ways to interact and collaborate -- instant messaging, Slack, and so on -- but email still dominates in enterprises.

Even as encryption goes mainstream with secure messaging tools, more websites adopting HTTPS by default, and cloud storage services allowing easier file encryption, sending an encrypted email message is still a challenge. While GPG Sync, a new open source project from First Look Code, doesn't simplify the process of sending encrypted messages, it does "make using encrypted email within an organization less obnoxious for everyone," wrote Micah Lee, a technologist with First Look Code, the software arm of First Look Media. GPG Sync is designed for organizations already doing the heavy lifting by using the public key cryptography implementation GPG (Gnu Privacy Guard) to encrypt email messages. Using GPG is a multistep affair, first creating the user's key, then regularly importing the keys of other users, and verifying the keys actually belong to the correct person. Making sure everyone has the most current key for everyone else is an unwieldy task. New keys are issued to new users as they join, so they need to be imported.
If existing users revoke keys and transition to new keys, other users need to refresh the keys to make sure they are not accidentally using the older keys.

This is the problem GPG Sync solves, by making sure each of the users have up-to-date public keys as defined by a centrally managed list. The project takes a very straightforward approach.

A single trusted person maintains a list of GPG fingerprints used by the organization, which is digitally signed by an "authority key." Each user's copy of GPG Sync recognizes the authority key's fingerprint and knows the URL of where the signed list is stored.

The software automatically makes sure the user has the most current list and references it to refresh all of the nonrevoked keys from a key server.  "Now each member of your organization will have up-to-date public keys for each other member, and key changes will be transitioned smoothly without any further work or interaction," Lee wrote on the project's GitHub page. GPG Sync plays a similar role as S/MIME or certificate authorities in many organizations and is a simpler alternative for organizations that don't want to set up a central authority. It's hard enough using GPG for encrypting emails, so simplifying key management is a real benefit. The caveat is that organizations must already have users set up to encrypt messages with PGP. While there are teams using open source security implementations like OpenPGP, many organizations concerned about encrypted email often prefer commercial offerings, such as Virtru.

The platform sits on top of the organization's existing email system, making it possible for users to send and receive encrypted messages without changing their workflow.
Virtru also provides a secure process for non-Virtru users to access encrypted messages. Projects like GPG Sync are beneficial for the overall open source security ecosystem because they simplify parts of an existing workflow. Making it easier to handle different steps makes the prospect of adopting GPG less daunting. Secure communications suffer from the chicken-and-egg problem. Users like the idea of sending secure messages, but they need to make sure the people they are communicating with are on the same service.
In the world of secure text messaging, users wind up with multiple apps on their mobile devices and have to remember which contact is on which platform to be able to communicate.

Apple encrypting iMessage end-to-end solved that problem for a lot of iOS users, and services like ProtonMail offers free encrypted webmail, but there's still a lot left to do to bring encryption to the masses.