• John Goerzen: Tips for Upgrading to, And Securing, Debian Buster

  Wow.  Once again, a Debian release impresses me — a guy that’s been using Debian for more than 20 years.  For the first time I can ever recall, buster not only supported suspend-to-disk out of the box on my laptop, but it did so on an encrypted volume atop LVM.  Very impressive!

  For those upgrading from previous releases, I have a few tips to enhance the experience with buster.

• Clear Linux Could Soon Be Faster Within Containers On AVX2 Systems

  While Clear Linux as part of its standard bare metal installations has long defaulted to having an AVX2-optimized GNU C Library installed by default, it turns out that it wasn't part of the default os-core bundle as used by containers. That though is changing and should yield even better out-of-the-box performance when running Clear Linux within containers.

  Intel's William Douglas sent out the proposal for adding the AVX2 version of the Glibc libraries into the os-core bundle in order to get picked up by containers and other bare/lightweight Clear configurations.

• OpenSUSE Enables LTO By Default For Tumbleweed - Smaller & Faster Binaries

  The past few months openSUSE developers have been working on enabling LTO by default for its packages while now finally with the newest release of the rolling-release openSUSE Tumbleweed this goal has been accomplished. 

  As of today, the latest openSUSE Tumbleweed release is using Link-Time Optimizations (LTO) by default. For end-users this should mean faster -- and smaller -- binaries thanks to the additional optimizations performed at link-time. Link-time optimizations allow for different optimizations to be performed at link-time for the different bits comprising a single module/binary for the entire program. Sadly not many Linux distributions are yet LTO'ing their entire package set besides the aggressive ones like Clear Linux. 

• Investigating why my 7-year old Windows 10 laptop became unbearably slow

  The laptop had also begun to run into blue screens of death (BSoD) whenever I used the built-in camera and when I opened Spotify or Netflix in a web browser. The slowdown and crashes were actually related, but I didn’t realize this at first. The camera-induced BSoD error message blamed the camera vendor’s driver without any further details. This sounds believable enough for a 7-year old laptop so I didn’t think any more of it.

There have been a total of five openSUSE Tumbleweed snapshots since the beginning of July and all the snapshots have a strong, stable rating.

The rolling release had the most updates arrive in the 20190702 snapshot. The packages update in that snapshot included Mesa 19.1.1 and Mesa-drivers 19.1.1 that had fixes for Intel ANV and AMD RADV driver as well as Nouveau and R300 Gallium3D drivers. The bzip2 file compression application fixed undefined behavior in the macros in version 1.0.7 and fixed a low impact Common Vulnerabilities and Exposures (CVE). The programing language package guilef was updated to version 2.2.5 and provided bootstrap optimization. Portability improvements were made in the library for encryption, decryption, signatures and password hashing with libsodium 1.0.18. A major release of the PulseAudio’s Volume Control package pavucontrol 4.0 was made; the new version dropped support for Gtk+ 2 and added more than a handful of new language translations.

The most recent snapshot, 20190708, didn’t offer a changelog due to the server that the web app uses to produce the changelogs being upgraded to Leap 15.1. The changelog is expected to be included in the next snapshot that is released.

• openSUSE.Asia Summit 2019 Logo Competition Winner

  The votes are in and the openSUSE Project is happy to announce that the openSUSE.Asia Summit 2019 logo competition winner is Hervy Qurrotul from Indonesia. Congratulations Hervy! As the winner, Hervy will receive a “mystery box” from the committee.

  On this logo competition, we have 18 submissions from all over the world. All the designs are great. This logo competition is voted by openSUSE.Asia Committee and Local Team. Thank you for your vote.

• Cloud Application Platform vs Container as a Service vs VM hosted application

  In the “old days,” applications were always hosted in a traditional way on a physical server or a group of physical servers. However, physical servers are expensive, hard to maintain and hard to grow and scale. That’s when virtual machines (VM) grew in popularity. VMs provided a better way to maintain, grow and scale. That is, they were easier to backup and restore and migrate from one region to another and they were easier to replicate across multiple domains/zones/regions.

• Sysadmin vs SRE: What's the difference?

  In the IT world, there has always been a pull between generalist and specialist. The stereotypical sysadmin falls in the generalist category 99 times out of 100. The site reliability engineer (SRE) role is specialized, however, and grew out of the needs of one of the first companies to know real scale: Google. Ultimately, these two roles have the same goal for the applications whose infrastructure they operate: providing a good experience for the applications’ consumers. Yet, these roles have drastically different starting points.

• An openSUSE foundation proposal

  The idea of spinning openSUSE out into a foundation is not new; it has come up multiple times along the way. The most recent push started back in April at two separate board meetings where it was discussed. It picked up steam during a board meeting at the openSUSE Conference 2019 in late May. While waiting for the outcome from that meeting (though there was a panel session with the board [YouTube] at the conference where some of the thinking was discussed), the community discussed ideas for a name for the foundation (and, possibly, the project itself). Now, board member Simon Lees has posted a draft of the foundation proposal for review.

  The proposal outlines the current thinking of the board. It notes that the move to a foundation is not meant to pull away from SUSE, "but to add more capabilities to the openSUSE Project". In particular, having a separate entity will allow the project to "receive and provide sponsorships (in terms of money, hardware, or contracted services)". Currently, any kind of agreement between the project and some other organization has to be done via SUSE, which can complicate those efforts. The new foundation would be able to partner with others, receive donations, spend money, and sign contracts with venues, service providers, and the like, all on behalf of the openSUSE project.

  SUSE would clearly have a role in the new foundation; the board is requesting some funding to set up the organization as well as one or two people to help with the administrative side. The new foundation's board would take the place of the existing project board, with the same election rules as there are today (which results in a board of six, five elected from the members of the project and the chair appointed by SUSE).

  The board is looking at setting up a German stiftung foundation as the legal entity for the new organization, though that was not clearly specified in the draft proposal. An eingetragener Verein (e. V.) was considered, but the structure of that type of entity is inflexible; in addition, the purpose of an e. V. can be changed if there was a "hostile takeover" at some point. Umbrella organizations (e.g. the Linux Foundation) and simply keeping things the same were also looked at, but were deemed unworkable for various reasons.

  There is also a handful of open questions, including logistical issues such as whether SUSE or the new foundation would own the IT infrastructure, trademarks, and so on. Also, who would be responsible (in a GDPR sense) for the project's data collection and storage. The biggest open issue is to create a charter for the foundation, which requires legal advice. The Document Foundation (TDF) is something of a model for what openSUSE is trying to achieve; it is also a stiftung and shares some of the attributes with the proposed structure.

• CVE-less vulnerabilities

  More bugs in free software are being found these days, which is good for many reasons, but there are some possible downsides to that as well. In addition, projects like OSS-Fuzz are finding lots of bugs in an automated fashion—many of which may be security relevant. The sheer number of bugs being reported is overwhelming many (most?) free-software projects, which simply do not have enough eyeballs to fix, or even triage, many of the reports they receive. A discussion about that is currently playing out on the oss-security mailing list.

• C, Fortran, and single-character strings

  The calling interfaces between programming languages are, by their nature, ripe for misunderstandings; different languages can have subtly different ideas of how data should be passed around. Such misunderstandings often have the effect of making things break right away; these are quickly fixed. Others can persist for years or even decades before jumping out of the shadows and making things fail. A problem of the latter variety recently turned up in how some C programs are passing strings to Fortran subroutines, with unpleasant effects on widely used packages like LAPACK.

  The C language famously does not worry much about the length of strings, which simply extend until the null byte at the end. Fortran, though, likes to know the sizes of the strings it is dealing with. When strings are passed as arguments to functions or subroutines, the GCC Fortran argument-passing conventions state that the length of each string is to be appended to the list of arguments. 

• Statistics from the 5.2 kernel — and before

  As of this writing, just over 13,600 non-merge changesets have been pulled into the mainline repository for the 5.2 development cycle. The time has come, once again, for a look at where that work came from and who supported it. There are some unique aspects to 5.2 that have thrown off some of the usual numbers.
  1,716 developers contributed changes for the 5.2 kernel, 245 of whom made their first contribution during this cycle. Those 1,716 developers removed nearly 490,000 lines of code, which is a lot, but the addition of 596,000 new lines of code means that the kernel still grew by 106,000 lines. 

• Lockdown as a security module

  Technologies like UEFI secure boot are intended to guarantee that a locked-down system is running the software intended by its owner (for a definition of "owner" as "whoever holds the signing key recognized by the firmware"). That guarantee is hard to uphold, though, if a program run on the system in question is able to modify the running kernel somehow. Thus, proponents of secure-boot technologies have been trying for years to provide the ability to lock down many types of kernel functionality on secure systems. The latest attempt posted by Matthew Garrett, at an eyebrow-raising version 34, tries to address previous concerns by putting lockdown under the control of a Linux security module (LSM).
  The lockdown patches have a long and controversial history; LWN first wrote about them in 2012. Opposition has come at all kinds of levels; some developers see lockdown as a way of taking control of systems away from their owners, while others see it as ultimately useless security theater. There does appear to be some value, though, in making a system as resistant to compromise as possible, so these patches have persisted and are often shipped by distributors. Disagreement over more recent versions of the lockdown patch set were focused on details like whether lockdown should be tied to the presence of secure boot or integration with the integrity-measurement infrastructure.

  One outcome from the most recent discussion was a concern that the lockdown patches were wiring too much policy into the kernel itself. The kernel has long had a mechanism for pushing security-policy decisions out to user space — the security-module mechanism. So it arguably makes sense to move lockdown decision-making into an LSM; that is indeed what the more recent versions of the patch set do.

  First, though, there is the problem of initialization. LSMs exist to apply policies to actions taken by user space, so as long as the LSM infrastructure is running by the time user space starts, everything is fine. Lockdown, though, must act earlier: it needs to be able to block the action of certain types of command-line parameters and must be functional even before a security policy can be loaded. So the patch set starts by creating a new type of "early security module" that is initialized toward the beginning of the boot process. At this point, the module can't do much — even basic amenities like kmalloc() are not available — but it's enough to register its hooks and take control.