Plovdiv Military Prosecutor’s office is all open source!

Plovdiv is a province in Bulgaria which you may have never heard of. However, something out of the ordinary is going on there, literally exemplifying the limits of open source usage in Government offices. The Military Prosecutor’s office in Plovdiv uses a combined solution of Debian and Ubuntu along with other open source software for all their computing needs.

The authority at the Military prosecutor’s office ensures that IT admins are well-versed in using open source solutions and even open source programming and configuration tools like Bash, Python and PHP. Most devices run Debian. Web services are a mix of Apache, Lighttpd and Ngix web servers on Debian hosts. The IT department uses similar hosts for routing and provisioning network services. To take it further, backup and replication services, which are different customized services developed in-house, are hosted on Debian systems too. Internal multimedia files are hosted using Getstream, Icecast and played using the popular media player VLC running on some Ubuntu hosts as well.

Gijs Hillenius of Joinup writes, “Open source solutions are used in all parts of the organisation at the Military Prosecutor’s office in the Bulgarian province of Plovdiv. The public administration’s IT staff by default uses the Debian and Ubuntu free software distributions, which has found its way to all kinds of computing devices, large and tiny. The use of these solutions helps the organisation save thousands of euro.”

Ubuntu running on some of the systems is also a common operating system besides Debian. The employees are free to choose between OpenOffice and LibreOffice. Moreover, they also use client workstations and many smaller devices based on boards running x86/x86_64, Raspberry Pi, CubieTruck and PicoIP some of which are used for access control services and others for surveillance.

Source: Joinup

KDE team looking for Debian contributors

On behalf of the KDE team, Maximiliano Curia has recently called on the Debian contributors for supporting them with integrating KDE into Debian. Citing the main reason behind the request as shortage of enough people to contribute to all the necessary areas, the KDE team points out that they are overloaded with the many packages they maintain and the kinds of bugs they have to deal with. They do have automation tools but that is simply not enough. And hence the pledge to the Debian developers to work in collaboration with KDE and help them shape up KDE for Debian.

The current areas listed for support are:

  • Bug triaging: Contributors should go through the bugs in the bug tracking system (BTS), understand the problem and how to reproduce it and confirm that they are still present in the latest versions. In particular, attention is needed to the bugs affecting the version in wheezy.
  • Bug forwarding: Help needed on forwarding those bugs to upstream which users do not forward themselves.
  • Patch forwarding: Debian-specific patches which also apply to upstream should be forwarded duly to save time in the future. This task is quite important.
  • Upgrade-testing: To avoid the painful experience of upgrading from one stable Debian release to another in the past for KDE software users, people are needed to try upgrading from wheezy to jessie and report any bugs they find.
  • Creating patches: Writing patches for existing bugs, some of which are easy and some are harder.
  • Packaging other KDE apps: Creating packages for useful components which are yet to get packaged.
  • Updating KDE’s welcoming wiki page, adding these tasks and any future tasks, and unifying the todo lists:
    https://wiki.debian.org/KDETodo
    https://wiki.debian.org/KdeDebTasks
    http://pkg-kde.alioth.debian.org/todo.html
    gobby://gobby.debian.org/Teams/KDE/TODO

Contributors interested in the above tasks are welcome to join the irc channel #debian-qt-kde in irc.oftc.net, or the debian-qt-kde mailing list.

SteamOS affected by Heartbleed bug, Valve yet to update the OS

A vulnerability that resulted from a bug in the OpenSSL security package has been found affecting a lot of Linux distributions. SteamOS, Valve’s custom OS based on Debian “Wheezy”, has also been affected, but the company has not made any announcements or patches available to patch out the vulnerability.

The vulnerability, named the Heartbleed bug is a bug that has been present in the OpenSSL cryptographic security package for quite some time now, but it was not discovered until recently and subsequently solved, quite akin to the Y2K bug that we had faced at the turn of the century. It is still not known though; whether this bug had been exploited before it was discovered to steal confidential information. However, since a large number of Linux distributions have been affected by this bug, the internet has been pretty riled up since its discovery. A general warning for users to change their passwords on systems that have been identified to have been affected by the bug and patched out has been sent out. Along with that, a dedicated website to the Heartbleed bug has also come up, signifying just how important this bug’s threat is to the internet.

According to the website, “The Heartbleed Bug is a serious vulnerability in the popular OpenSSL cryptographic software library. This weakness allows stealing the information protected, under normal conditions, by the SSL/TLS encryption used to secure the Internet. SSL/TLS provides communication security and privacy over the Internet for applications such as web, email, instant messaging (IM) and some virtual private networks (VPNs).”

Even though most Linux distributions and affected platforms have been patched to overcome this vulnerability, the SteamOS hasn’t yet been patched for this bug. Although the base, Debian “Wheezy”, on which the OS is based on has received the patch, SteamOS has not benefitted from it. The reason behind it is that users on Debian can simply download the incremental patch, whereas SteamOS users have to wait for Valve to integrate the path into the SteamOS environment rather than just update the system like its proper Debian. So SteamOS users are left vulnerable till Valve comes out with a patch. So far, Valve has not said anything on the official channels. We will keep you updated as and when the update or any further news on the subject becomes available.

Source: Softpedia

Linux Mint Debian 201403 Released

The Linux Mint team has released a new edition of Linux Mint Debian which comes with a revamped desktop and updated software. Unlike other editions of Linux Mint which use Ubuntu repositories and packages as the base, Linux Mint Debian uses Debian testing repositories for its packages.

Some of the highlights of this release are:

  • Linux Mint Update Pack 8
  • Cinnamon 2.0
  • MATE 1.6
  • Latest Mint tools
  • Support for EFI and GPT

The release is available for both 32 and 64 bit architectures and requires a moderate PC with 1GB of RAM, 5GB diskspace and a VGA capable graphics card to run. As this edition uses Debian Testing, the OS is semi rolling and you don’t need to reformat every time a new edition releases. This is especially suitable for users who want a stable system which will run a long time without any major changes.

You can download Linux Mint Debian Edition in both Cinnamon and MATE editions from mirrors listed in this page. Torrent download is also available, in case you need a higher speed download and wish to reduce the load of Linux Mint servers.

Debian TC fails to reach decision over init system coupling

It wasn’t all that long ago that the Debian Technical Committee decided on systemd over other alternative init systems, such as OpenRC, UpStart, and more. When the resolution passed that systemd would be the default in Debian GNU\Linux Jesse, a lot of us in the Linux sphere breathed a sigh of relief. Recently, init system coupling was brought up for a vote. What init system coupling details, is whether or not the Debian team should offer any guidance concerning packages for specific init systems. The votes follow a specific structure:

L: Software may not depend on a specific init system
N: No TC resolution on this question at this time
A: Advice: sysvinit compatibility in Jessie and multiple init support
FD: Further discussion

With all 8 votes cast, the CFV on the init system coupling issue ended in a tie between options “L” and “N”. Using executive decision on the matter, Bdale Garbee voted ‘N’. He wrote on the mailing list,  “Given my vote on this issue, it should be no surprise that I use my casting vote to declare option “N” is the winner.”

Therefore:
The TC chooses to not pass a resolution at the current time about whether software may require specific init systems.

TC committee member Ian Jackson has called for another vote, this time concerning the Debian constitution. Among proposed changes were the removal of the 2:1 supermajority for TC overrides, FD voting thresholds, discussion period length, and clarify ownership of resolution draft versions.

Debian backed Mempo project Emphasises security

One interesting project that I saw recently was the Mempo project, headed by the illustrious Debian team. More and more projects are springing up lately, in the post Snowden era, security is of high concern for many users. Tools, such as proxy servers, SSH tunnelling, and decentralized browsers such as the infamous Tor browser all try to maintain privacy in the interests of users. Trust is always an issue, and having Debian at the help of Mempo should show some interest in the favor of the user, rather than that of corporate interest. The Mempo project has the ultimate goal of being the “most secure and yet comfortable out-of-the-box Desktop and Server computer, for professionals, business, journalists, and every-day users avoiding PRISM-like spying.”

Although the project is still in a very early pre-alpha stage, the code and software stack is readily available for testing. Code review is still in progress, though you can review the source code yourself for closer inspection. Mempo is trying it’s best to help protect unsuspecting users from hardware level attacks, root-kits, cold-boot, hacking NIC PCI cards, bugs in e.g. Xen, fire-wire attacks, and more.

mempo-system-layers

The structure of Mempo follows a hierarchical pyramid structure, placing Memp in-between the OS layer and Virtual layers and on down the line. Mempo makes use of several other pieces of software to pull all the necessary pieces together to create the feature list they present. Mempo even goes as far as reaching into user applications, allowing users to preconfigure them for best security practices.

Mempo’s layers are fairly stacked, with several software pieces filling each layer. Coreboot with a hardened Read-Only boot+MBR handles the first layer with the Grsecurity+PAX (instead of SELinux) and custom patches handling the Kernel process. Full root encryption takes over with a hidden filesytem, with one-time, PIN, USB-key passwords and a patched display server. Then comes the Mempo manager, allowing creation of VMs, isolated users, and management of the Mempo ecosystem. In the VM space, the Xen prject and Qubes OS drive this creation and management. When it comes to networking, the highly profile Tor network is made use of, as well as Freenet, I2P, VPNs, all stackable and configurable.

Mempo takes security quite seriously, taking full advantage of known technologies such as PGP, Multi-Crypt, and secure random generators with entropy. You can compare security cases yourself on the Mempo project page. The Mempo name derives from its dictionary definition concerning types of facial armor worn by the Samurai class during feudal Japan.

The Mempo source code is available now on GitHub. Again, please keep in mind this is only a pre-alpha release, and is in the very early stages of development. As it stands today, the project is a mere 15% complete, but already much has been done. It must be said that Mempo, especially at this point is meant mostly for advanced users, although any one is free to tackle the early project of course. The Mempo team tells us in the near future, a distro/repo will be available for a much easier installation. You can however install the Mempo software stack on top of Debian stable for a similar experience.

The team has a call out for aspiring users to debug code, evangelicalism, or even donations. If you wish to contact the Debian team behind Mempo, the Contact section has many ways you can get in touch with them. Installation wasn’t too teeth-grating in my experience, but I am just getting to the early stages of trying all the features currently available.

The tools are out there, will you take the steps necessary to safeguard yourself?

Source: Debian Wiki

Finally, Debian chose* systemd as default init systemd, bye bye upstart

As we reported earlier that Debian Technical Committee was voting on the default init system for Debian and votes were point at systemd beating Upstart which was supported only by the Canonical employees who were in the TC.

Today Bdale Garbee has cast his vote to choose D as the winner, which already had majority votes.

Announcing systemd as the default init system of Debian Bdale wrote:

Therefore, the resolution reads:

We exercise our power to decide in cases of overlapping jurisdiction (6.1.2) by asserting that the default init system for Linux architectures in jessie should be systemd.

Should the project pass a General Resolution before the release of “jessie” asserting a “position statement about issues of the day” on init systems, that position replaces the outcome of this vote and is adopted by the Technical Committee as its own decision.

Bdale

systemd already has a wide adoption withing the GNU/Linux distribution with all major distros including openSUSE, Fedora, Arch Linux, etc using it as their default init system. Upstart was either way not getting much support from the free software community due to the restrictive CLAs Canonical requires which is often criticized by the community. With Debian going* for systemd, it will get even more developer power whereas Canonical will be left alone to deal with Upstart along with many more project that it’s trying to do on its own – including the recently discussed File Manager which may replace Nautilus (Files).

*Update: Some members are calling for GR – General Resolution which may override this voting and may drag this discussion for ever, so it’s not final yet.

Debian 7.4 released

The Debian project has announced the release of Debian 7.4 “wheezy“, which is the fourth maintenance release in Debian 7.x series. This is mainly a maintenance release which addresses many Security related issues of the stable release. The Debian teams have already published the security advisories separately.

Neil McGovern of the Debian project says, “Please note that this update does not constitute a new version of Debian 7 but only updates some of the packages included. There is no need to throw away old “wheezy” CDs or DVDs but only to update via an up-to-date Debian mirror after an installation, to cause any out of date packages to be updated.”

If you already keep your Debian box update (which you should) then you won’t have to install too many packages.

Valve offers free games to Ubuntu developers

Valve Software recently announced that they would offer free Valve games to all Debian developers, which was considered a way of saying thank you to the base that is used to create Steam OS.

While Steam OS has nothing to do with Ubuntu, the company is now expanding that offer to Ubuntu developers as well. All registered Ubuntu developers will get complete access to all current and future Valve games for fee.

Canonical top-shots have expressed their excitement for this announcement.

Mark Shuttleworth wrote on the mailing list, “That’s super – thanks Neil! Please pass appreciation on to the relevant person at Valve.”

Jono Bacon, the Community manager at Canonical, writes on his Google+ page, “Many thanks to +Valve for offering Ubuntu developers free games in addition to Debian – https://lists.ubuntu.com/archives/ubuntu-devel-announce/2014-February/001079.html – well there goes their weekends. :-)”

The offer is being managed by Collabora. Registered Ubuntu developers can request their key by emailing to Jo Shields. Get more info here.

Debian technical committee votes for systemd over Upstart

Debian technical committee was discussing the default init system for Debian and it boiled down to basically systemd, which is developed by the larger free software community (lead by Lennart Poettering), and Upstart which was developed by Canonical employees.

Systemd has become the preferred choice of all major GNU/Linux desktop operating systems. However what Debian goes with impacts Ubuntu, which is based on Debian. Ubuntu uses Upstart and Ubuntu developer at Debian’s TC were, for obvious and appropriate reasons, pushing for Upstart.

Bdale Garbee,chairman of the Debian Technical Committee, called for a ballot from the TC to chose the default init system. He wrote on the mailing list:

We exercise our power to decide in cases of overlapping jurisdiction (6.1.2) by asserting that the default init system for Linux architectures in jessie should be

D systemd
U upstart
O openrc
V sysvinit (no change)
F requires further discussion

Should the project pass a General Resolution before the release of “jessie” asserting a “position statement about issues of the day” on init systems, that position replaces the outcome of this vote and is adopted by the Technical Committee as its own decision.

The votes are in and systemd seems to be the clear winner here.

Bdale himself voted for systemd.

The discussion continues but it looks like systemd will be the default init system for Debian. Is it going to effect Ubuntu or it’s derivatives like Linux Mint of Kubuntu – we will see when those projects will speak out.

Most developers are against Canonical’s Upstart for technical as well as legal reasons – Canonical requires developers to sign it’s CLAs in order to contribute to it’s code-base. Lead Open Source developers have repeatedly raised their concerns regarding Canonical’s CLAs.

Linus Torvalds, creator of the Linux kernel, says, “To be fair, people just like hating on Canonical. The FSF and Apache Foundation CLA’s are pretty much equally broken. And they may not be broken because of any relicencing, but because the copyright assignment paperwork ends up basically killing the community. Basically, with a CLA, you don’t get the kind of “long tail” that the kernel has of random drive-by patches. And since that’s how lots of people try the waters, any CLA at all – changing the license or not – is fundamentally broken.”