FLOSS Project Planets

Dirk Eddelbuettel: RcppArmadillo 0.7.700.0.0

Planet Debian - Wed, 2017-02-08 21:24

Time for another update of RcppArmadillo with a new release 0.7.700.0.0 based on a fresh Armadillo 7.700.0. Following my full reverse-dependency check of 318 package (commit of log here), CRAN took another day to check again.

Armadillo is a powerful and expressive C++ template library for linear algebra aiming towards a good balance between speed and ease of use with a syntax deliberately close to a Matlab. RcppArmadillo integrates this library with the R environment and language--and is widely used by (currently) 318 other packages on CRAN -- an increase of 20 just since the last CRAN release of 0.7.600.1.0 in December!

Changes in this release relative to the previous CRAN release are as follows:

Changes in RcppArmadillo version 0.7.700.0.0 (2017-02-07)
  • Upgraded to Armadillo release 7.700.0 ("Rogue State")

    • added polyfit() and polyval()

    • added second form of log_det() to directly return the result as a complex number

    • added range() to statistics functions

    • expanded trimatu()/trimatl() and symmatu()/symmatl() to handle sparse matrice

Changes in RcppArmadillo version 0.7.600.2.0 (2017-01-05)
  • Upgraded to Armadillo release 7.600.2 (Coup d'Etat Deluxe)

    • Bug fix to memory allocation for fields

Courtesy of CRANberries, there is a diffstat report. More detailed information is on the RcppArmadillo page. Questions, comments etc should go to the rcpp-devel mailing list off the R-Forge page.

This post by Dirk Eddelbuettel originated on his Thinking inside the box blog. Please report excessive re-aggregation in third-party for-profit settings.

Categories: FLOSS Project Planets

Iustin Pop: Solarized colour theme

Planet Debian - Wed, 2017-02-08 20:18

A while back I was looking for some information on the web, and happened upon a blog post about the subject. I don't remember what I was looking for, but on the same blog, there was a screen shot of what I then learned was the Solarized theme. This caught my eye that I decided to try it myself ASAP.

Up until last year, I've been using for many years the 'black on light yellow' xterm scheme. This is good during the day, but too strong during night, so on some machines I switched to 'white on black', but this was not entirely satisfying.

The solarized theme promises to have consistent colours over both light and dark background, which would help to make my setups finally consistent, and extends to a number of programs. Amongst these, there are themes for mutt on both light and dark backgrounds using only 16 colours. This was good, as my current hand-built theme is based on 256 colours, and this doesn't work well in the Linux console.

So I tried changing my terminal to the custom colours, played with it for about 10 minutes, then decided that its contrast is too low, bordering on unreadable. I switch to another desktop where I still had open an xterm using white-on-black, and—this being at night—my eyes immediately go 'no no no too high contrast'. In about ten minutes I got so used to it that the old theme was really really uncomfortable. There was no turning back now ☺

Interestingly, the light theme was not that much better than black-on-light-yellow, as that theme is already pretty well behaved. But I still migrated for consistency.


Starting from the home page and the internet, I found resources for:

  • Vim and Emacs (for which I use the debian package elpa-solarized-theme).
  • Midnight Commander, for which I currently use peel's theme, although I'm not happy with it; interestingly, the default theme almost works on 16-custom-colours light terminal scheme, but not quite on the dark one.
  • Mutt, which is both in the main combined repository but also on the separate one. I'm not really happy with mutt's theme either, but that seems mostly because I was using a quite different theme before. I'll try to improve what I feel is missing over time.
  • dircolors; I found this to be an absolute requirement for good readability of ls --color, as the defaults are too bad
  • I also took the opportunity to unify my git diff and colordiff theme, but this was not really something that I found and took 'as-is' from some repository; I basically built my own theme.
16 vs 256 colours

The solarized theme/configuration can be done in two ways:

  • by changing the Xresources/terminal 16 basic colours to custom RGB values, or:
  • by using approximations from the fixed 256 colours available in the xterm-256color terminfo

Upstream recommends the custom ones, as they are precisely tuned, instead of using the approximated ones; honestly I don't know if they would make a difference. It's too bad upstream went silent a few years back, as technically it's possible to override also colours above 16 in the 256-colour palette, but in any case, each of the two options has its own cons:

  • using customised 16-colour means that all terminal programs get the new colours scheme, even if they were designed (colour-wise) based on the standard values; this makes some things pretty unreadable (hence the need to fix dircolors), but at least somewhat consistent.
  • using 256-colour palette, unchanged programs stay the same, but now they look very different than the programs that were updated to solarized; note thought I haven't tested this, but that's how I understand things would be.

So either way it's not perfect.

Desktop-wide consistency

Also not perfect is that for proper consistent look, many more programs would have to be changed; but I don't see that happening in today's world. I've seen for example 3 or 4 Midnight Commander themes, but none of them were actually in the spirit of solarized, even though they were tweaked for solarized.

Even between vim and emacs, which both have one canonical solarized theme, the look is close but not really the same (looking at the markdown source for this blog post: URLs, headers and spelling mistakes are all different), but this might be due not necessarily the theme itself.

So no global theme consistency (I'd wish), but still, I find this much better on the eyes and not lower on readability after getting used to it.

Thanks Ethan!

Categories: FLOSS Project Planets

Steve Kemp: Old packages are interesting.

Planet Debian - Wed, 2017-02-08 20:00

Recently Vincent Bernat wrote about writing his own simple terminal, using vte. That was a fun read, as the sample code built really easily and was functional.

At the end of his post he said :

evilvte is quite customizable and can be lightweight. Consider it as a first alternative. Honestly, I don’t remember why I didn’t pick it.

That set me off looking at evilvte, and it was one of those rare projects which seems to be pretty stable, and also hasn't changed in any recent release of Debian GNU/Linux:

  • lenny had 0.4.3-1.
  • etch had nothing.
  • squeeze had 0.4.6-1.
  • wheezy has release 0.5.1-1.
  • jessie has release 0.5.1-1.
  • stretch has release 0.5.1-1.
  • sid has release 0.5.1-1.

I wonder if it would be possible to easily generate a list of packages which have the same revision in multiple distributions? Anyway I had a look at the source, and unfortunately spotted that it didn't entirely handle clicking on hyperlinks terribly well. Clicking on a link would pretty much run:

firefox '%s'

That meant there was an obvious security problem.

It is a great terminal though, and it just goes to show how short, simple, and readable such things can be. I enjoyed looking at the source, and furthermore enjoyed using it. Unfortunately due to a dependency issue it looks like this package will be removed from stretch.

Categories: FLOSS Project Planets

Manuel A. Fernandez Montecelo: FOSDEM 2017: People, RISC-V and ChaosKey

Planet Debian - Wed, 2017-02-08 19:52

This year, for the first time, I attended FOSDEM.

There I met...


... including:

  • friends that I don't see very often;
  • old friends that I didn't expect to see there, some of whom decided to travel from far away in the last minute;
  • met people in person for the first time, which previously I had known only though the internet -- one of whom is a protagonist in a previous blog entry, about the Debian port for OpenRISC;

I met new people in:

  • bars/pubs,
  • restaurants,
  • breakfast tables at lodgings,
  • and public transport.

... from the first hour to the last hour of my stay in Brussels.

In summary, lots of people around.

I also hoped to meet or spend some (more) time with a few people, but in the end I didn't catch them, our could not spend as much time with them as I would wish.

For somebody like me who enjoys quiet time by itsef, it was a bit too intensive in terms of interacting with people. But overall it was a nice winter break, definitely worth to attend, and even a much better experience than what I had expected.

Talks / Events

Of course, I also attended a few talks, some of which were very interesting; although the event is so (sometimes uncomfortably) crowded that the rooms were full more often than not, in which case it was not possible to enter (the doors were closed) or there were very long queues for waiting.

And with so many talks crammed into a weekend, I had so many schedule clashes with the talks that I had pre-selected as interesting, that I ended up missing most of them.

In terms of technical stuff, I have specially enjoyed the talk by Arun Thomas RISC-V -- Open Hardware for Your Open Source Software, and some conversations related with toolchain stuff and other upstream stuff, as well as on the Debian port for RISC-V.

The talk Resurrecting dinosaurs, what can possibly go wrong? -- How Containerised Applications could eat our users, by Richard Brown, was also very good.


Apart from that, I have witnessed a shady cash transaction in a bus from the city centre to FOSDEM in exchange for hardware, not very unlike what I had read about only days before.

So I could not help but to get involved in a subsequent transaction myself, to get my hands laid upon a ChaosKey.

Categories: FLOSS Project Planets

Drupal Association blog: Call for Design Partners

Planet Drupal - Wed, 2017-02-08 19:33

The Drupal Association is seeking a design partner for creative, graphic and website design services for a new DrupalCon brand. We're looking for people who understand the Drupal community, Drupal the project, software innovation, and our extreme nerdiness - and know how to turn these things into compelling designs that are functional, fun, and make people look twice. 

Main Deliverables

  • Overall conference branding
  • Content hierarchy and IA for the DrupalCon website
  • Design and theming
  • Digital and print graphics design

Scope of Work

The design partner's work will reinforce a positive brand image of DrupalCon to attendees and within the Drupal community year-round. The design should reflect DrupalCon's position as a major international software conference and the community connections that make DrupalCon a unique event. The SOW may include, but is not limited to, the following:

  • Overall creative design of DrupalCon brand
  • Digital outreach: newsletter templates, social media profiles (theme/icons), badges, ads
  • Signage: venue signage, banners, sponsor signs
  • Materials: slide decks, volunteer/staff clothing, giveaway items
  • Print: letterhead/templates, badgelettes, sponsorship guide
  • Style guide: production and use guides
  • Theming for the DrupalCon website


The design partner will coordinate final design deliverables and production schedule with Drupal Association staff, and will actively participate in weekly planning meetings. 

Proposal Process

Please download the complete RFP which outlines the proposal process and requirements, and provides specific instructions on submission and question and answer processes. 


Proposals are due February 22, 2017 23:49 EST (UTC-5). Please refer to the RFP for a full award timeline. 

Selection Criteria

The respondent whole proposal best meets the needs of the project will be selected according to the following criteria:

  • Thoroughness of proposal
  • Demonstrated understanding of the project
  • Quality of work samples provided
  • Outcome of phone/video interview
  • Availability and responsiveness of the project team


The Drupal Association's budget for DrupalCon design work is $30,000. The designer or company will also receive public recognition on the site via footer credits for 3 years and volunteer credits, and will receive a Bronze Sponsorship for the 2018 North America DrupalCon. 

Categories: FLOSS Project Planets

Mediacurrent: Rethinking Theme Structure in Drupal 8

Planet Drupal - Wed, 2017-02-08 16:50

Most web pages share pieces that are reused throughout the entire site. While I’ve heard them called different things, I prefer to call them components. Some examples include the header, footer, main navigation, logo, slideshow and so on. Most of these can be broken down into smaller components as well. For example, maybe the header is a specific layout that includes the main navigation and the logo.

Categories: FLOSS Project Planets

Mike Driscoll: New in Python: Formatted string literals

Planet Python - Wed, 2017-02-08 14:15

Python 3.6 added yet another way to do string substitution that they are calling “Formatted String Literals”. You can read all about the concept in PEP 498. I take a bit of umbrage here in that the Zen of Python states that There should be one– and preferable only one –obvious way to do it. Now Python has three ways. Let’s take a walk down memory lane before we talk about the latest way to play with strings.

Ye Olde String Substitution

When Python first started, they followed C++ in the way they did string substitution by using %s, %i and the like. Here are a couple of examples:

>>> The %s fox jumps the %s' % ('quick', 'crevice') 'The quick fox jumps the crevice' >>> foo = 'The total of your purchase is %.2f' % 10 >>> foo 'The total of your purchase is 10.00'

The second example above demonstrates how to format a number into a float with a precision set to 2 decimal places. This method of string substitution also supports keyword arguments:

>>> 'Hi, my name is %(name)s' % {'name': 'Mike'} Out[21]: 'Hi, my name is Mike'

The syntax is a little odd and I always have to look it up to get it to work correctly.

While these methods of string substitution are still supported, a new method was invented that was supposed to be clearer and more functional. Let’s see how that looks:

>>> bar = 'You need to pay {}'.format(10.00) >>> bar 'You need to pay 10.0' >>> swede = 'The Swedish chef is know for saying {0}, {1}, {2}'.format('bork', 'cork', 'spork') >>> swede 'The Swedish chef is know for saying bork, cork, spork'

I thought this was a pretty clever new addition. However there was an additional enhancement in that you could actually use keyword arguments to specify what goes where in a string substitution:

>>> swede = 'The Swedish chef is know for saying {something}, {something}, {something}' >>> swede.format(something='bork') 'The Swedish chef is know for saying bork, bork, bork' >>> test = 'This is a {word} of your {something}'.format(word='Test', something='reflexes') >>> test 'This is a Test of your reflexes'

This is pretty cool and actually quite useful. You will see some programmers that will argue over which method is to be preferred. I have seen some even claim that the original method is actually faster than the newer one if you are doing a lot of string substitutions. Regardless, this gives you a brief glimpse of the old way of doing things. Let’s see what’s new!

Using Formatted String Literals


Starting in Python 3.6, we get Formatted String Literals or f-string. The syntax for a formatted string literal is a bit different than what we’ve seen previously:

>>> name = 'Mike' >>> f'My name is {name}' 'My name is Mike'

Let’s break this down a bit. The first thing we do is define a variable that we want to insert into a string. Next we want to tell Python that we want to create a formatted string literal. To do this, we prepend our string with the letter “f”. That means the string will be formatted. The final piece is quite similar to our last example from the previous section in that we just need to insert our variable name into the string with a pair of curly braces around it. Then Python does some magic and we get a new string printed out. This is actually quite similar to some of the Python templating languages, such as mako.

The f-string also supports certain types of conversions, such as str() via ‘!s’ and repr() via ‘!r’. Here’s an updated example:

>>> f'My name is {name!r}' Out[11]: "My name is 'Mike'"

You will note that the change in the output is pretty subtle in that all that was added is some single quotes around the variable that was inserted. Let’s take a look at something a bit more complicated, namely floating point numbers!

>>> import decimal >>> gas_total = decimal.Decimal('20.345') >>> width = 10 >>> precision = 4 >>> f'Your gas total is: {gas_total:{width}.{precision}}' 'Your gas total is: 20.34'

Here we import Python’s decimal module and create an instance of that represents a gas total. Then we set up the width of the string to be 10 characters and the precision to be 4. Finally we tell the f-string to format it for us. As you can see, the inserted text has some padding on the front end to make it 10 characters wide and the precision basically set it to 4 which truncated the 5 instead of rounding up.

Wrapping Up

The new Formatted String Literal or f-string doesn’t really add anything new to formatting strings. However it is claimed to be more flexible and less error-prone than the previous methods. I highly recommend reading the documentation and PEP 498 to help you get up to speed on this new feature so you can determine if this is the way you will be doing string substitution in the future.

Related Reading

Categories: FLOSS Project Planets

Amjith Ramanujam: Maintainer Stories

Planet Python - Wed, 2017-02-08 13:25

Github produced a video series called "Maintainer Stories". One of the videos is about my experiences as a maintainer of pgcli

Categories: FLOSS Project Planets

Mediacurrent: If You Wanna Be My Vendor ...

Planet Drupal - Wed, 2017-02-08 13:16

If you wanna be my vendor, you’ve gotta get with my friends: Drupal, Open Source, and Communication.

Categories: FLOSS Project Planets

Antoine Beaupré: Reliably generating good passwords

Planet Debian - Wed, 2017-02-08 13:00

Passwords are used everywhere in our modern life. Between your email account and your bank card, a lot of critical security infrastructure relies on "something you know", a password. Yet there is little standard documentation on how to generate good passwords. There are some interesting possibilities for doing so; this article will look at what makes a good password and some tools that can be used to generate them.

There is growing concern that our dependence on passwords poses a fundamental security flaw. For example, passwords rely on humans, who can be coerced to reveal secret information. Furthermore, passwords are "replayable": if your password is revealed or stolen, anyone can impersonate you to get access to your most critical assets. Therefore, major organizations are trying to move away from single password authentication. Google, for example, is enforcing two factor authentication for its employees and is considering abandoning passwords on phones as well, although we have yet to see that controversial change implemented.

Yet passwords are still here and are likely to stick around for a long time until we figure out a better alternative. Note that in this article I use the word "password" instead of "PIN" or "passphrase", which all roughly mean the same thing: a small piece of text that users provide to prove their identity.

What makes a good password?

A "good password" may mean different things to different people. I will assert that a good password has the following properties:

  • high entropy: hard to guess for machines
  • transferable: easy to communicate for humans or transfer across various protocols for computers
  • memorable: easy to remember for humans

High entropy means that the password should be unpredictable to an attacker, for all practical purposes. It is tempting (and not uncommon) to choose a password based on something else that you know, but unfortunately those choices are likely to be guessable, no matter how "secret" you believe it is. Yes, with enough effort, an attacker can figure out your birthday, the name of your first lover, your mother's maiden name, where you were last summer, or other secrets people think they have.

The only solution here is to use a password randomly generated with enough randomness or "entropy" that brute-forcing the password will be practically infeasible. Considering that a modern off-the-shelf graphics card can guess millions of passwords per second using freely available software like hashcat, the typical requirement of "8 characters" is not considered enough anymore. With proper hardware, a powerful rig can crack such passwords offline within about a day. Even though a recent US National Institute of Standards and Technology (NIST) draft still recommends a minimum of eight characters, we now more often hear recommendations of twelve characters or fourteen characters.

A password should also be easily "transferable". Some characters, like & or !, have special meaning on the web or the shell and can wreak havoc when transferred. Certain software also has policies of refusing (or requiring!) some special characters exactly for that reason. Weird characters also make it harder for humans to communicate passwords across voice channels or different cultural backgrounds. In a more extreme example, the popular Signal software even resorted to using only digits to transfer key fingerprints. They outlined that numbers are "easy to localize" (as opposed to words, which are language-specific) and "visually distinct".

But the critical piece is the "memorable" part: it is trivial to generate a random string of characters, but those passwords are hard for humans to remember. As xkcd noted, "through 20 years of effort, we've successfully trained everyone to use passwords that are hard for human to remember but easy for computers to guess". It explains how a series of words is a better password than a single word with some characters replaced.

Obviously, you should not need to remember all passwords. Indeed, you may store some in password managers (which we'll look at in another article) or write them down in your wallet. In those cases, what you need is not a password, but something I would rather call a "token", or, as Debian Developer Daniel Kahn Gillmor (dkg) said in a private email, a "high entropy, compact, and transferable string". Certain APIs are specifically crafted to use tokens. OAuth, for example, generates "access tokens" that are random strings that give access to services. But in our discussion, we'll use the term "token" in a broader sense.

Notice how we removed the "memorable" property and added the "compact" one: we want to efficiently convert the most entropy into the shortest password possible, to work around possibly limiting password policies. For example, some bank cards only allow 5-digit security PINs and most web sites have an upper limit in the password length. The "compact" property applies less to "passwords" than tokens, because I assume that you will only use a password in select places: your password manager, SSH and OpenPGP keys, your computer login, and encryption keys. Everything else should be in a password manager. Those tools are generally under your control and should allow large enough passwords that the compact property is not particularly important.

Generating secure passwords

We'll look now at how to generate a strong, transferable, and memorable password. These are most likely the passwords you will deal with most of the time, as security tokens used in other settings should actually never show up on screen: they should be copy-pasted or automatically typed in forms. The password generators described here are all operated from the command line. Password managers often have embedded password generators, but usually don't provide an easy way to generate a password for the vault itself.

The previously mentioned xkcd cartoon is probably a common cultural reference in the security crowd and I often use it to explain how to choose a good passphrase. It turns out that someone actually implemented xkcd author Randall Munroe's suggestion into a program called xkcdpass:

$ xkcdpass estop mixing edelweiss conduct rejoin flexitime

In verbose mode, it will show the actual entropy of the generated passphrase:

$ xkcdpass -V The supplied word list is located at /usr/lib/python3/dist-packages/xkcdpass/static/default.txt. Your word list contains 38271 words, or 2^15.22 words. A 6 word password from this list will have roughly 91 (15.22 * 6) bits of entropy, assuming truly random word selection. estop mixing edelweiss conduct rejoin flexitime

Note that the above password has 91 bits of entropy, which is about what a fifteen-character password would have, if chosen at random from uppercase, lowercase, digits, and ten symbols:

log2((26 + 26 + 10 + 10)^15) = approx. 92.548875

It's also interesting to note that this is closer to the entropy of a fifteen-letter base64 encoded password: since each character is six bits, you end up with 90 bits of entropy. xkcdpass is scriptable and easy to use. You can also customize the word list, separators, and so on with different command-line options. By default, xkcdpass uses the 2 of 12 word list from 12 dicts, which is not specifically geared toward password generation but has been curated for "common words" and words of different sizes.

Another option is the diceware system. Diceware works by having a word list in which you look up words based on dice rolls. For example, rolling the five dice "1 4 2 1 4" would give the word "bilge". By rolling those dice five times, you generate a five word password that is both memorable and random. Since paper and dice do not seem to be popular anymore, someone wrote that as an actual program, aptly called diceware. It works in a similar fashion, except that passwords are not space separated by default:

$ diceware AbateStripDummy16thThanBrock

Diceware can obviously change the output to look similar to xkcdpass, but can also accept actual dice rolls for those who do not trust their computer's entropy source:

$ diceware -d ' ' -r realdice -w en_orig Please roll 5 dice (or a single dice 5 times). What number shows dice number 1? 4 What number shows dice number 2? 2 What number shows dice number 3? 6 [...] Aspire O's Ester Court Born Pk

The diceware software ships with a few word lists, and the default list has been deliberately created for generating passwords. It is derived from the standard diceware list with additions from the SecureDrop project. Diceware ships with the EFF word list that has words chosen for better recognition, but it is not enabled by default, even though diceware recommends using it when generating passwords with dice. That is because the EFF list was added later on. The project is currently considering making the EFF list be the default.

One disadvantage of diceware is that it doesn't actually show how much entropy the generated password has — those interested need to compute it for themselves. The actual number depends on the word list: the default word list has 13 bits of entropy per word (since it is exactly 8192 words long), which means the default 6 word passwords have 78 bits of entropy:

log2(8192) * 6 = 78

Both of these programs are rather new, having, for example, entered Debian only after the last stable release, so they may not be directly available for your distribution. The manual diceware method, of course, only needs a set of dice and a word list, so that is much more portable, and both the diceware and xkcdpass programs can be installed through pip. However, if this is all too complicated, you can take a look at Openwall's passwdqc, which is older and more widely available. It generates more memorable passphrases while at the same time allowing for better control over the level of entropy:

$ pwqgen vest5Lyric8wake $ pwqgen random=78 Theme9accord=milan8ninety9few

For some reason, passwdqc restricts the entropy of passwords between the bounds of 24 and 85 bits. That tool is also much less customizable than the other two: what you see here is pretty much what you get. The 4096-word list is also hardcoded in the C source code; it comes from a Usenet sci.crypt posting from 1997.

A key feature of xkcdpass and diceware is that you can craft your own word list, which can make dictionary-based attacks harder. Indeed, with such word-based password generators, the only viable way to crack those passwords is to use dictionary attacks, because the password is so long that character-based exhaustive searches are not workable, since they would take centuries to complete. Changing from the default dictionary therefore brings some advantage against attackers. This may be yet another "security through obscurity" procedure, however: a naive approach may be to use a dictionary localized to your native language (for example, in my case, French), but that would deter only an attacker that doesn't do basic research about you, so that advantage is quickly lost to determined attackers.

One should also note that the entropy of the password doesn't depend on which word list is chosen, only its length. Furthermore, a larger dictionary only expands the search space logarithmically; in other words, doubling the word-list length only adds a single bit of entropy. It is actually much better to add a word to your password than words to the word list that generates it.

Generating security tokens

As mentioned before, most password managers feature a way to generate strong security tokens, with different policies (symbols or not, length, etc). In general, you should use your password manager's password-generation functionality to generate tokens for sites you visit. But how are those functionalities implemented and what can you do if your password manager (for example, Firefox's master password feature) does not actually generate passwords for you?

pass, the standard UNIX password manager, delegates this task to the widely known pwgen program. It turns out that pwgen has a pretty bad track record for security issues, especially in the default "phoneme" mode, which generates non-uniformly distributed passwords. While pass uses the more "secure" -s mode, I figured it was worth removing that option to discourage the use of pwgen in the default mode. I made a trivial patch to pass so that it generates passwords correctly on its own. The gory details are in this email. It turns out that there are lots of ways to skin this particular cat. I was suggesting the following pipeline to generate the password:

head -c $entropy /dev/random | base64 | tr -d '\n='

The above command reads a certain number of bytes from the kernel (head -c $entropy /dev/random) encodes that using the base64 algorithm and strips out the trailing equal sign and newlines (for large passwords). This is what Gillmor described as a "high-entropy compact printable/transferable string". The priority, in this case, is to have a token that is as compact as possible with the given entropy, while at the same time using a character set that should cause as little trouble as possible on sites that restrict the characters you can use. Gillmor is a co-maintainer of the Assword password manager, which chose base64 because it is widely available and understood and only takes up 33% more space than the original 8-bit binary encoding. After a lengthy discussion, the pass maintainer, Jason A. Donenfeld, chose the following pipeline:

read -r -n $length pass < <(LC_ALL=C tr -dc "$characters" < /dev/urandom)

The above is similar, except it uses tr to directly to read characters from the kernel, and selects a certain set of characters ($characters) that is defined earlier as consisting of [:alnum:] for letters and digits and [:graph:] for symbols, depending on the user's configuration. Then the read command extracts the chosen number of characters from the output and stores the result in the pass variable. A participant on the mailing list, Brian Candler, has argued that this wastes entropy as the use of tr discards bits from /dev/urandom with little gain in entropy when compared to base64. But in the end, the maintainer argued that reading "reading from /dev/urandom has no [effect] on /proc/sys/kernel/random/entropy_avail on Linux" and dismissed the objection.

Another password manager, KeePass uses its own routines to generate tokens, but the procedure is the same: read from the kernel's entropy source (and user-generated sources in case of KeePass) and transform that data into a transferable string.


While there are many aspects to password management, we have focused on different techniques for users and developers to generate secure but also usable passwords. Generating a strong yet memorable password is not a trivial problem as the security vulnerabilities of the pwgen software showed. Furthermore, left to their own devices, users will generate passwords that can be easily guessed by a skilled attacker, especially if they can profile the user. It is therefore essential we provide easy tools for users to generate strong passwords and encourage them to store secure tokens in password managers.

Note: this article first appeared in the Linux Weekly News.

Categories: FLOSS Project Planets

Acquia Developer Center Blog: 246: Don't miss Drupal Camp London 2017!

Planet Drupal - Wed, 2017-02-08 12:54

A conversation about the event and why you should be there, too, this time around with Ben Wilding and Waliur Rahman, members of the 2016 Drupal Camp London organizing team.

Come along March 3-5, 2017, to Europe's biggest (best?) community event on the calendar!

Tickets and information here: http://drupalcamp.london

Skill Level: BeginnerIntermediateAdvanced
Categories: FLOSS Project Planets

Acquia Developer Center Blog: Drupal 8 Module (Distro!) of the Week: Open Social

Planet Drupal - Wed, 2017-02-08 11:51

This week: Open Social, a community-building distribution // Drupal 8 has more and more features available practically every day. Alongside module migrations and new projects, the Drupal community’s latest major release also offers new ways of solving common problems. Some functionality has moved to Drupal core and new modules have taken up the torch along the way. In this series, the Acquia Developer Center is profiling useful solutions--modules, themes, distros, and more--available for Drupal 8.

Tags: acquia drupal planetopen socialintranetcommunity
Categories: FLOSS Project Planets

FSF Blogs: Free Software Directory meeting recap for February 3rd, 2017

GNU Planet! - Wed, 2017-02-08 10:44

Every week free software activists from around the world come together in #fsf on irc.freenode.org to help improve the Free Software Directory. This recaps the work we accomplished at the Friday, February 3rd, 2017 meeting.

Last week's theme focused on web authoring tools. These are the programs that enable users to shape the contours of web. With over five hundred entries in the web authoring tools category alone, there was no way that a single meeting could cover all the entries. The meeting, while lightly populated, got right down to work on the weekly theme. Time was spent looking at light web servers as well as web proxy programs. The entry review spread to cover web site management programs too. By the end, entries were consolidated, others updated, and a few removed. This was all done with the goal of improving the Directory.

If you would like to help improve the directory, meet with us every Friday in #fsf on irc.freenode.org from 12 p.m. to 3 p.m. EST (17:00 to 20:00 UTC).

Categories: FLOSS Project Planets

Free Software Directory meeting recap for February 3rd, 2017

FSF Blogs - Wed, 2017-02-08 10:44

Every week free software activists from around the world come together in #fsf on irc.freenode.org to help improve the Free Software Directory. This recaps the work we accomplished at the Friday, February 3rd, 2017 meeting.

Last week's theme focused on web authoring tools. These are the programs that enable users to shape the contours of web. With over five hundred entries in the web authoring tools category alone, there was no way that a single meeting could cover all the entries. The meeting, while lightly populated, got right down to work on the weekly theme. Time was spent looking at light web servers as well as web proxy programs. The entry review spread to cover web site management programs too. By the end, entries were consolidated, others updated, and a few removed. This was all done with the goal of improving the Directory.

If you would like to help improve the directory, meet with us every Friday in #fsf on irc.freenode.org from 12 p.m. to 3 p.m. EST (17:00 to 20:00 UTC).

Categories: FLOSS Project Planets

Mike Driscoll: Pyowa Meeting (Feb 2017)

Planet Python - Wed, 2017-02-08 10:42

The local Python users group, Pyowa, was restarted last night after a year and a half hibernation. I hadn’t been to one of their meetings in a few years, but I had decided at the end of 2016 to get it going again. Once the ball was rolling, we got multiple offers of sponsorships for the meeting and ended up going with Pillar Technology for our first meeting of 2017. They call their space The Forge and they provided pizza and refreshments. They are located in downtown Des Moines.

We had around 23 or so people show up including the staff from Pillar. Our speaker was Jesse Horne from Pioneer and he talked about Chalice, a Python Serverless Microframework for AWS (Amazon Web Services). Chalice is kind of a lightweight Flask. Jesse ended up writing a very basic book database web application. While there were some technical issues, the crowd was very supportive and helpful and I thought that the meeting went quite well. There was even a robot wandering around that was remote controlled by one of the employees of Pillar.

The next meeting is currently scheduled for March 7th @ Pioneer. Keep an eye on Pyowa’s website for an update to get the latest information.

Categories: FLOSS Project Planets

Made with Krita 2016: The Artbooks Have Arrived!

Planet KDE - Wed, 2017-02-08 10:42

Made With Krita 2016 is now available! This morning the printer delivered 250 copies of the first book filled with art created in Krita by great artists from all around the world. We immediately set to work to send out all pre-orders, including the ones that were a kickstarter reward.

The books themselves are gorgeous. The artwork is great and varied, of course, but the printer did a good job on the colors, too — helped by the excellent way the open source desktop publishing application Scribus prepares PDF’s for printing. The picture doesn’t do it justice, since it was made with an old phone…

Forty artists from all over the world, working in all kinds of styles and on all kinds of subjects show how Krita is used in the real world to create amazing and engaging art. The book also contains a biographical section with information about each individual artist. Get your rare first edition now, an essential addition to every self-respecting bookshelf! The book is professionally printed on 130 grams paper and softcover bound in signatures.

The cover illustration is by Odysseas Stamoglou. The inner artwork features Arrianne Criseyde Pascual, Baukje Jagersma, Beelzy, Chewsome, David Revoy, Enrico Guarnieri, Eric Lee, Filipe Ferreira, Justin Nichol, Kesbet Tree, Livio Fania, Liz de Souza, Matt Preece, Melissa Lipan, Michael Bowling, Mozart Couto, Naghree Greenskin, Neotheta, Nivailis, Paolo Puggioni, R.J. Quiralta, Radian 1, Raghukamath, Ramón Miranda, Reine, Sylvain Boussiron, William Thorup, Elésiane Huve, Amelia Hamrick, Danilo Junior, Ivan Aros, Jennifer Reuter, Karen Kaye Llamas, Lucas Ribeiro, Motion Arc Foundry, Odysseas Stamoglou, Sylvia Ritter, Timothée Giet, Tony Jennison, Tyson Tan, and Wayne Parker.

Made with Krita 2016

Made with Krita 2016 is 19,95€ excluding VAT in the European Union, excluding shipping. Shipping is 11.25€ outside the Netherlands and 3.65€ inside the Netherlands.


European Union:


Categories: FLOSS Project Planets

Plasma Sprint: KDE neon Docker Images Now Support Wayland

Planet KDE - Wed, 2017-02-08 10:05

The KDE neon Docker Images are the easiest and fastest way to test out KDE software from a different branch than your host system.

Coming live from the Plasma Sprint sponsored by Affenfels here in Stuttgart, the KDE neon Docker images now support Wayland.  This runs on both X and Wayland host systems.  Instructions on the wiki page.

Below you can see my host system running Plasma 5.9 on X is running Plasma master with Wayland.

Hugs to David E.

Categories: FLOSS Project Planets

health @ Savannah: Meet the GNU Health team at SCALE15x !

GNU Planet! - Wed, 2017-02-08 09:45

Dear all

I am happy to announce that GNU Health will be an exhibitor in the Southern California Linux Expo, SCALE15x, that will take place in Pasadena, California, during March 2nd - 5th

The GNU Health team will be at booth 313. We will be setting up talks and discussions during those days. We'll be updating the events agenda, but please take a look at https://www.socallinuxexpo.org/scale/15x/sponsor/gnu-health for more info on the main topics. Don't miss this unique opportunity to get a sneak preview and discuss the latest and coolest features for upcoming version with the core GNU Health developers !

  • Volunteers : If you want to participate as a GNU Health volunteer, please contact me, so we can arrange the logistics.
  • Supporters : People that wants to join the event to support GNU Health, there is a special promo code provided by the organization that will make a 50% discount.

We are very happy and excited about SCALE15x. We also want to express our gratitude to the organization, for being so kind and inviting us !

I am confident it will be a great experience to meet the GNU Health community, as well as to interact with the other great Free Software communities that will be attending too.

Looking forward to meeting you at SCALE15x !


Dr. Luis Falcon, M.D., BSc
President, GNU Solidario
GNU Health: Freedom and Equity in Healthcare

Categories: FLOSS Project Planets

Zato Blog: API endpoints with unformatted input and FTP

Planet Python - Wed, 2017-02-08 08:36

While JSON or SOAP-wrapped messages are ubiquitous in HTTP-based APIs, there are times when unformatted messages are of advantage.

This article will explain how to create Zato endpoints accessing such data and to top it off, will also introduce the concept of outgoing FTP connections through which requests can be stored at remote FTP resources.


Hot-deploy the following service onto a Zato cluster.

The key point is self.request.raw_request - this is how a programmer can access input data as it was received by Zato prior to its de-serialization from JSON or XML.

Note that this attribute will be available even if parsing took place, that is, one can always access raw request no matter what data format was used on input.

# Zato from zato.common.util import fs_safe_now from zato.server.service import Service class FTPHandler(Service): """ Stores anything that is given on input at a remote FTP server pointed to by an outgoing connection called 'my.ftp'. """ def handle(self): # Obtain handle to an FTP connection by its name conn = self.outgoing.ftp.get('my.ftp') # Create file name in a format that is safe for file-systems, # i.e. no colons or whitespace. file_name = '/home/api/request.{}'.format(fs_safe_now()) # Store file on FTP conn.setcontents(file_name, self.request.raw_request) Configuration

Now that the code is deployed, we need configuration to plug it into the whole framework. Use web-admin to create two objects per screenshots below.

One is an HTTP channel that exposes the deployed service through an HTTP channel - note that 'Data format' was left blank so as not to require JSON or XML on input.

The other is a definition of the FTP server that the service will store files in.

Don't forget to set password for the newly configured FTP connection to log in with in run-time.

As always with Zato, one's code never accesses any resources directly, everything is routed through named objects such as self.outgoing.ftp['my.ftp'] that actually point to a required resource. In this manner, if anything needs to be reconfigured, it can be done on fly, without changes to code and without server restarts.


With code deployed and configuration created, we can now upload sample data from command line and confirm it's made its way to an FTP server.

And sure enough - the file is there!


Accessing raw requests in Zato services is trivially easy. Likewise, making use of FTP connections is a matter of a single line of code, while hot-deployment and configuration mean that changes introduced in web-admin are immediately reflected all throughout a Zato cluster.

Want more?

Categories: FLOSS Project Planets

Nick Kew: No FOSDEM

Planet Apache - Wed, 2017-02-08 07:30

I didn’t make it to FOSDEM last weekend.

This time I could perfectly well have done so: there was nowhere else I had to be, no deadline I was pressed to meet, no travel difficulties.  No such excuse.  I just didn’t go.

My loss.  Certainly in terms of who I didn’t meet (old friends and new), what I didn’t learn, how my mind didn’t get stimulated, what projects and ideas haven’t excited me.  Damn.

So what kept me away?  Obviously it’s that bit harder work than higher-budget conferences.  The venue is a bit hit-and-miss, with some of the rooms being quite an ordeal.  On the other hand, the big lecture theatre with the keynotes and the smaller ones where most talks happen are perfectly good, the room with the “lightning talks” (always a good default place if there’s a time when you have nothing scheduled) likewise, and the better project rooms are good for a session – at least when there’s something in that limited space of interesting but not too overcrowded and stuffy.

No, what really put me off was the prospect of once again running the gamut of the smokers.  The stench of it in the lobby and corridors, exhibition space and coffee area, coupled with the crowds that prevent getting from A to B on a single breath.  The good reasons to go to FOSDEM are at an intellectual level, but the feeling of a descent into filth when I think about going is overwhelming at a basic, Proustian level.

On that analysis, I may never go again.  That’s sad.

Categories: FLOSS Project Planets
Syndicate content