Feed aggregator

Joachim Breitner: Dreaming of role playing

Planet Debian - Thu, 28/01/2016 - 08:26

Recently, at a summer-school-like event, we were discussing pen-and-paper role playing. I’m not sure if this was after a session of role-playing, but I was making the point that you don’t need much or any at all of the rules, and scores, and dice, if you are one of the story-telling role players, and it can actually be more fun this way.

As an example, I said, it can make sense if one of the players (and the game master, I suppose) reads up a lot about one aspect of the fantasy world, e.g. one geographical area, one cult, one person, and then this knowledge is used to create an exciting puzzle, even without any opponents.

I’m not quite sure, but I think I fell asleep shortly after, and I dreamed of such a role playing session. It was going roughly like this:

I (a human), and my fellows (at least a dwarf, not sure about the rest) went to some castle. It was empty, but scary. We crossed its hall, and went into a room on the other side. It was locked towards the hall by a door that covered the door frame only partly, and suddenly we could see a large Ogre, together with other foul folk not worth mentioning, hammered at the door. My group (which was a bit larger in that moment) all prepared shooting arrows at him the moment it burst through the door. I had the time to appreciate the ingenuity that we all waited for him to burst through, so that none of the arrows would bounce of the door, but it did not help, and we ran from the castle, over a field, through a forest, at the other side of which we could see, below a sleep slope, a house, so we went there.

The path towards that was filled with tracks that looked surprisingly like car tracks. When we reached the spot there was no house any more, but rather a cold camp side. We saw digging tools, and helmets (strangely, baseball helmets) were arranged in a circle, as if it was a burial site.

We set up camp there and slept.

It occurred to me that I must have been the rightful owner of the castle, and it was taken by me from my brother and his wife, who denied my existence or something treacherously like that. When we woke up at the camp side, she were there, together with what must be my niece. My sister in law mocked us for fighting unsuccessfully at the castle, but my niece was surprised to see me, as I must have a very similar appearance to my brother. She said that her mother forbid it, but she nevertheless sneakily takes out something which looks like a Gameboy with a camera attachment and a CompactFlash card from her mothers purse, puts it in and take a photo of me. This is when I realize that I will get my castle back.

At that moment, I woke up. I somewhat liked the story (and it was a bit more coherent in my mind than what I then wrote down here), so I wanted to write it down. I quickly fetched my laptop. My friends at the summer school were a bit worried, and I promised not to mention their names and concrete places, and started writing. They distracted me, so I searched for a place of my own, lied down (why? no idea), and continued writing. I had to to touch writing on my belly, because my laptop was not actually there.

I also noticed that I am back at the camp side, and that I am still wearing my back protector that I must have been wearing while fighting in the castle, and which I did not take off while sleeping at the camp side. Funnily, it was not a proper medieval amour, but rather my snowboarding back protector.

At that moment, I woke up. I somewhat liked the story (and it was a bit more coherent in my mind than what I then wrote down here), so I wanted to write it down. I quickly got up, started my laptop, and wrote it down. And this is what you are reading right now.

Off to bed again, let’s see what happens next.

Categories: Elsewhere

Holger Levsen: 20160127-torbrowser-daily-tests

Planet Debian - Thu, 28/01/2016 - 02:17
Daily tests of torbrowser-launcher, and on every git commit too

Tor Browser for reasons beyond this blog post is not part of Debian. To easily and securely use it, one can run

sudo apt-get install torbrowser-launcher and then run torbrowser-launcher which will download Tor Browser and well, launch it. And this sometimes breaks, when things change, which is rather frequently the case…

So yesterday I finally woke up to see what I wished to see every morning since November 15th last year, when I started testing torbrowser-launcher systematically on jenkins.debian.net:

This is the graphical status overview of torbrowser tests on Debian which are tests installing torbrowser-launcher on and from sid, stretch, jessie-backports, jessie and wheezy-backports, which first download torbrowser via https and via tor, then launches it to finally connect to a debian mirror via an onion-address and then to www.debian.org. In addition to these there are also tests installing the package from stretch on jessie as well as the package from sid on stretch and jessie. Finally there are also tests for building the package from our git branches for various suites and finally we also build a package based on the upstream git master branch merged with our sid packaging.

There are 17 different tests currently and they are configured in just two files, a 220 line yaml file defining the jenkins jobs and 528 lines of bash script containing the actual test code. The tests are using schroot, xvfb, kvkbd and gocr and are executed either daily or weekly (those testing the package from ftp.d.o) or on every commit and at least once every month (those testing the package build from git).

At least briefly I have been looking at the this page every day since setting up these tests two months ago. Back then, torbrowser-launcher was broken in many suites and then it broke some more and instead of fixing it, I first made these tests so that at least in future there will be automatic notifications when things break. This has worked out rather nicely and torbrowser-launcher got fixed over time too. Doing so in jessie proper took longest as we missed 8.2. Once jessie was fixed the fix for wheezy-backports was also finally accepted very quickly. Which was this Monday, so yesterday on Tuesday I could enjoy for the first time an all "green page"!

And then on Wednesday, which is now also yesterday, the nice green page became less green due two new issues: #805173 really needs ca-certificates as depends and not recommends and then also the rendering of the new 5.5 version of torbrowser changed slightly… Both issues have been addressed by now.

I'm curious how this page will look tomorrow morning. And when I'll consider it the number of false negatives to be low enough so as I'll happily enable notifications to be send to the pkg privacy maintainers mailing list. I think it's almost the case and will keep an eye on the results the coming weeks and months.

Last not least: if you want to run similar tests for your Debian project, I'd be glad to help! See you at FOSDEM?

Categories: Elsewhere

drunken monkey: Great progress in the Search API D8 version

Planet Drupal - Wed, 27/01/2016 - 23:56

The last two months finally saw rapid progress in the development of the Search API module's Drupal 8 version. Acquia generously agreed to fund all available time for both Joris Vercammen (borisson_) and me in December and January to work on this port and related modules (especially Facets).

What we did

With this backing, we were able to make a lot of head-way and got a lot of large blocking issues out of the way, among them a overhaul for the fields UI, some necessary major internal refactorings and most of the Views integration. All of this is now baked into the new Alpha 12 release, created today. Over the next couple of days, we will then also create releases for the other related modules with a working D8 version: Facets, Search API Solr Search, Search API attachments (Alpha 2) and maybe also Search API pages.
That way, we should be able to avoid a confusion of versions and conflicts for any users interested in trying out the current state of work of this module suite, or already starting to build a new site using them.
Going forth, we will also try to keep this system of creating a set of compatible releases for future Alpha versions.

As noted in the release notes, though, be careful when building sites already with this module version, as there will be no upgrade paths until Beta and some changes until then are still likely to break the storage structure (and would thus lead to loss of configuration, unless handled correctly). Also, this release (like all other non-stable releases for any module) will not be covered by Drupal's Security Team, so any discovered security vulnerabilities would be reported, worked on and fixed publicly.

That being said, though, one of the greatest improvements in the module's D8 version, at least under the hood, is it's vastly improved test coverage. That, along with Drupal.org's automated testing, enables us to be very confident in each new feature we add and each bug we fix, thus also improving the maintainability and speed of feature development in the future. And it hopefully makes it much less likely that any major bugs go unnoticed for long.
But there are also lots of improvements visible right on the surface: we carefully reviewed all major encountered problems and pitfalls with the module's D7 version and worked to make the new D8 version another large leap forward to support as many search use cases as possible, while still becoming much more user-friendly than the D7 version – probably one of the largest points of criticism overall.

Still to do

So, how does it look for the further path towards a stable D8 release for the Search API (and, subsequently, for its numerous add-on modules)?
Currently, there are no immediate plans for further funding, so while I will of course still work on the port whenever I can, the pace will necessarily slack down a bit again. I also neglected maintenance of my various D7 modules in the last months, so there's also a lot of catching-up to do there. (Incidentally, a great way to help this effort if you are not comfortable with D8 yet: just go into any of my modules' issue queues and try to answer support requests, reproduce or fix bugs, test patches, etc., there.)
However, while there are still a lot of beta blockers left, most of them are relatively minor compared to the ones we now resolved, so I think a first Beta release in March should be within reach. Then it will be a matter of determining the MVP for an initial stable release and working towards that – but I expect a much shorter period for Beta than it has been for Alpha, maybe only a month or two.

If you want to help with this in any way, please either ask around in the Search API IRC channel (#drupal-search-api on Freenode) or send me a message – or just jump into any issue and get cracking!

Categories: Elsewhere

DrupalEasy: DrupalEasy is Proudly Sponsoring Florida DrupalCamp (again!)

Planet Drupal - Wed, 27/01/2016 - 20:50
News item

Florida DrupalCamp is coming up on March 5th, and DrupalEasy is happy to be involved as a sponsor and organizer. This year's event will be better than ever, with three amazing featured speakers flying in from three different countries! Karen Stevenson, Morten DK, and Jesus Manuel Olivas will be presenting double-length sessions on the lastest Druapl 8-related topics.

-->

read more

Categories: Elsewhere

DrupalCon News: Meet the DrupalCon Asia Media Partners

Planet Drupal - Wed, 27/01/2016 - 17:56

Media partners are an important part of any DrupalCon. They help us spread the word about the event to people who might not have heard of it otherwise, and get to attend (and report on) the events. Our media partners are critical to DrupalCon's success, so we'd like to say a big thank you to all of our partners for DrupalCon Asia.

Categories: Elsewhere

Acquia Developer Center Blog: D8 Module Acceleration Program - January Releases

Planet Drupal - Wed, 27/01/2016 - 16:31
John Kennedy

I looked at my Drupal 8 Module Acceleration Program (D8 MAP) Trello board this morning and was struck with the enormity of what we have accomplished over the past 4 months.

If you want an overview of the Drupal 8 Module Acceleration Program check out my post on Acquia.com.

Tags: acquia drupal planet
Categories: Elsewhere

roomify.us: Speeding up Behat tests for Drupal on the Travis environment

Planet Drupal - Wed, 27/01/2016 - 16:03
Background Implementing continuous integration of behaviorally-driven tests is a fairly heavy-weight process. In order to run a comprehensive battery of test cases, it’s necessary to set up a complete testing environment for each commit. This involves things like:  downloading: a browser executable drush Drupal core  all dependent modules Behat itself Selenium installing Drupal instantiating an HTTP server Making this process as efficient as possible has many benefits, including preserving shared resources for public repos (or your money, for private repos!) and speeding up one’s entire development workflow. Below we will describe some of the tactics we employ to make testing on Travis faster.
Categories: Elsewhere

John Goerzen: Bach, Dot Matrix Printers, and Dinner

Planet Debian - Wed, 27/01/2016 - 15:50

Dinner last night started out all normal. Then Jacob and Oliver started asking me about printers. First they wanted to know how an ink jet printer works. Then they wanted to know how a laser printer works. Then they wanted to know what would happen if you’d put ink in a laser printer or toner in an ink jet. They were fascinated as I described the various kinds of clogging and ruining that would inevitably occur.

Then these words: “What other kinds of printers are there?”

So our dinner conversation started to resolve around printers. I talked about daisy wheel printers, line printers, dot matrix printers. I explained the type chain of line printers, the pins of dot matrix. “More printers!” I had to dig deeper into my memory: wax transfer printers, thermal printers, dye sublimation, always describing a bit about how each one worked — except for dye sublimation, which I couldn’t remember many details about. “More printers!” So we went onwards towards the printing press, offset printing, screen printing, mimeograph, and photocopiers. Although I could give them plenty of details about most of the printers, I also failed under their barrage of questions about offset printing. So I finally capitulated, and said “should I go get my phone and look it up while you finish eating?” “YEAH!”

So I looked up the misty details of dye sublimation and offset printing and described how they worked. That seemed to satisfy them. Then they asked me what my favorite kind of printer was. I said “dot matrix, because it makes the best sound.” That had their attention. They stopped eating to ask the vitally important question: “Dad, what sound does it make?” At this point, I did my best dot matrix impression at the dinner table, to much laughter and delight.

Before long, they wanted to see videos of dot matrix printers. They were fascinated by them. And then I found this gem of a dot matrix printer playing a famous Bach tune, which fascinated me also:

I guess it must have all sunk in, because this morning before school Jacob all of a sudden begged to see the fuser in my laser printer. So we turned it around, opened up the back panel — to his obvious excitement — and then I pointed to the fuser, with its “hot” label. I even heard a breathy “wow” from him.

Categories: Elsewhere

Russell Coker: Using LetsEncrypt

Planet Debian - Wed, 27/01/2016 - 14:15

Lets Encrypt is a new service to provide free SSL keys [1]. I’ve just set it up on a few servers that I run.

Issues

The first thing to note is that the client is designed to manage your keys and treat all keys on a server equally with a single certificate. It shouldn’t be THAT difficult to do things in other ways but it would involve extra effort. The next issue that can make things difficult is that it is designed that the web server will have a module to negotiate new keys automatically. Automatically negotiating new keys will be really great when we get that all going, but as I didn’t feel like installing a slightly experimental Apache module on my servers that meant I had to stop Apache while I got the keys – and I’ll have to do that again every 3 months as the keys have a short expiry time.

There are some other ways of managing keys, but the web servers I’m using Lets Encrypt with at the moment aren’t that important and a couple of minutes of downtime is acceptable.

When you request multiple keys (DNS names) for one server to make it work without needless effort you have to get them all in the one operation. That gives you a single key file for all DNS names which is very convenient for services that don’t support getting the hostname before negotiating SSL. But it could be difficult if you wanted to have one of the less common configurations such as having a mail server and a web server on the same IP addess but using different keys

How To Get Keys

deb http://mirror.internode.on.net/pub/debian/ testing main

The letsencrypt client is packaged for Debian in Testing but not in Jessie. Adding the above to the /etc/apt/sources.list file for a Jessie system allows installing it and a few dependencies from Testing. Note that there are problems with doing this, you can’t be certain that all the other apps installed will be compatible with the newer versions of libraries that are installed and you won’t get security updates.

letsencrypt certonly --standalone-supported-challenges tls-sni-01

The above command makes the letsencrypt client listen on port 443 to talk to the Lets Encrypt server. It prompts you for server names so if you want to minimise the downtime for your web server you could specify the DNS names on the command-line.

If you run it on a SE Linux system you need to run “setsebool allow_execmem 1” before running it and “setsebool allow_execmem 0” afterwards as it needs execmem access. I don’t think it’s a problem to temporarily allow execmem access for the duration of running this program, if you use KDE then you will be forced to allow such access all the time for the desktop to operate correctly.

How to Install Keys

[ssl:emerg] [pid 9361] AH02564: Failed to configure encrypted (?) private key www.example.com:443:0, check /etc/letsencrypt/live/www.example.com/fullchain.pem

The letsencrypt client suggests using the file fullchain.pem which has the key and the full chain of certificates. When I tried doing that I got errors such as the above in my Apache error.log. So I gave up on that and used the separate files. The only benefit of using the fullchain.pem file is to have a single line in a configuration file instead of 3. Trying to debug issues with fullchain.pem took me a lot longer than copy/paste for the 3 lines.

Under /etc/letsencrypt/live/$NAME there are symlinks to the real files. So when you get new keys the old keys will be stored but the same file names can be used.

SSLCertificateFile "/etc/letsencrypt/live/www.example.com/cert.pem"
SSLCertificateChainFile "/etc/letsencrypt/live/www.example.com/chain.pem"
SSLCertificateKeyFile "/etc/letsencrypt/live/www.example.com/privkey.pem"

The above commands are an example for configuring Apache 2.

smtpd_tls_cert_file = /etc/letsencrypt/live/smtp.example.com/cert.pem
smtpd_tls_key_file = /etc/letsencrypt/live/smtp.example.com/privkey.pem
smtpd_tls_CAfile = /etc/letsencrypt/live/smtp.example.com/chain.pem

Above is an example of Postfix configuration.

ssl_cert = </etc/letsencrypt/live/smtp.example.com/cert.pem
ssl_key = </etc/letsencrypt/live/smtp.example.com/privkey.pem
ssl_ca = </etc/letsencrypt/live/smtp.example.com/chain.pem

Above is an example for Dovecot, it goes in /etc/dovecot/conf.d/10-ssl.conf in a recent Debian version.

Conclusion

At this stage using letsencrypt is a little fiddly so for some commercial use (where getting the latest versions of software in production is difficult) it might be a better option to just pay for keys. However some companies I’ve worked for have had issues with getting approval for purchases which would make letsencrypt a good option to avoid red tape.

When Debian/Stretch is released with letsencrypt I think it will work really well for all uses.

No related posts.

Categories: Elsewhere

Modules Unraveled: 153 Protecting Drupal 8 Sites From Spam Using Honeypot with Jeff Geerling - Modules Unraveled Podcast

Planet Drupal - Wed, 27/01/2016 - 13:30
Published: Wed, 01/27/16Download this episodeHoneypot
  • What is the Honeypot module?
  • What prompted you to contribute the Honeypot module? Why was it originally created?
    Flocknote (two employers ago) user registration
    A bunch of my blogs / comments
  • What methods or techniques does honeypot use to detect bots?
    A literal ‘honeypot’
    Time delay
  • What types of foms can it protect?
  • What’s different about Honeypot vs. other spam prevention modules like CAPTCHA and Mollom?
    Avoid punishing the user (explain)
Drupal 8 and Future of Honeypot
  • How did the port of Honeypot to Drupal 8 go?
  • Have you started developing new sites in Drupal 8? And if so, how’s that going?
  • How have spammers adapted to tools like Honeypot, and how do you try to keep ahead of them?” “More spam getting through Honeypot lately” (https://www.drupal.org/node/2646380)
Community Issues
  • You’re also involved a bit in other open source communities for projects like Ansible. How does the Drupal community compare? What are some things you would like to see improved?
  • Is there anything you’ve done to make sure you can continue to maintain this open source project among many others both on drupal.org and github, and not get burned out?
Episode Links: Jeff Geerling on drupal.orgJeff Geerling on TwitterHoneypotAnsible for DevOpsDrupal VMTags: SpamDrupal 8planet-drupal
Categories: Elsewhere

Uwe Kleine-König: Installing Debian Jessie on a Netgear ReadyNAS 104

Planet Debian - Wed, 27/01/2016 - 12:03

The Netgear ReadyNAS 104 comes shipped with U-Boot. To access its "shell" remove the small quadratic sticker at the backside to reveal the UART pins (3V3, pinout available at Arnaud's NAS page[1] and connect a matching adapter. Also connect a network cable to the lower jack.

Then on a different machine in the same network setup a tftp server (e.g. apt-get install tftpd-hpa). As of today the latest beta netboot installer (Beta 2) doesn't work any more because the kernel in jessie was updated since the installer was released. So pick up the armhf netboot installer from the daily snapshots. You need initrd.gz and vmlinuz. Furthermore armada-370-netgear-rn104.dtb.

Update: As jessie is released now, download the following images:

To make the installer ready to boot do:

# apt-get install u-boot-tools $ cat vmlinuz armada-370-netgear-rn104.dtb > vmlinuz-rn104 $ mkimage -A arm -O linux -T multi -C none -a 0x04000000 -e 0x04000000 -n "Debian Jessie armhf installer" -d vmlinuz-rn104:initrd.gz uImage-installer-rn104 # cp uImage-installer-rn104 /srv/tftp

Then on the U-Boot shell setup networking and start the installer by issuing the following commands:

dhcp setenv serverip 192.168.1.17 tftp uImage-installer-rn104 bootm $load_addr

With 192.168.1.17 being the IPv4 of the machine you set up the tftp server above, adapt accordingly to your setup.

While in U-Boot the default ethernet device is the lower jack, the installer is only able to use the upper, so replug the ethernet cable to the upper receptacle.

Go through the installation, and before rebooting do the following: Select "Change debconf priority" and set it to "low". Then "Download installer components" and check "mtd-modules-3.16.0-4-armmp-di". After that "Execute a shell" and do:

# depmod -a # modprobe pxa3xx_nand # apt-install flash-kernel # mount --bind /proc /target/proc # chroot /target # cat >> /etc/flash-kernel/db << EOF Machine: NETGEAR ReadyNAS 104 DTB-Id: armada-370-netgear-rn104.dtb DTB-Append: yes Mtd-Kernel: uImage Mtd-Initrd: minirootfs U-Boot-Kernel-Address: 0x04000000 U-Boot-Initrd-Address: 0x05000000 Required-Packages: u-boot-tools EOF # flash-kernel

You then need to adapt the u-boot environment to pass the right root parameter to Linux. Alternatively add Bootloader-Sets-Incorrect-Root: yes to /etc/flash-kernel/db.

[1] Note this page is about a ReadyNAS 102, the pinout is identical though.

Categories: Elsewhere

DrupalCon News: Submit a Session for DrupalCon New Orleans

Planet Drupal - Wed, 27/01/2016 - 10:09

Think you’ve got Drupal or web smarts? We’re seeking mind-blowingly good sessions for DrupalCon New Orleans, and want to hear from you about what you know best.

We have a lot of opportunities to get your experience as part of the DrupalCon program and invite you to check out the multiple ways that you can share your knowledge and passion for Drupal after you look over our tips on how to get your proposal selected.

Categories: Elsewhere

Alessio Treglia: Quantum reflections of a winter evening

Planet Debian - Wed, 27/01/2016 - 09:40

 

A problem of interpretation?

December 14th, 1900 is known as the date of birth of quantum physics. In fact, that day Max Planck presented his report to the German Physical Society in Berlin, in which he argued that the exchange of energy in the phenomena of emission and absorption of electromagnetic radiation occurs in discrete form, not in continuous form as claimed by electromagnetic classic theory.

It was like opening a door to a new universe, that of subatomic particles. In a few decades it was learned that the basis of the strength of the real world around us (people, objects, plants, animals, etc.) is a joyful swarm of tiny particles distributed in clouds of probability, essentially surrounded by empty space. A shocking and apparently incomprehensible reality for the man of the ‘900: how could that still solid rock actually contain billions of microscopic “objects” in motion?

With the passing of the years, the road was covered deeper and deeper, revealing ever smaller particles for which new unknown names were coined: Leptons, Gluons, Quarks, Neutrinos, Fermions, Bosons, and so on until…

<Read More…>

Categories: Elsewhere

Lunar: ASLR now!

Planet Debian - Wed, 27/01/2016 - 09:05

Address space layout randomization helps to protect against buffer overflow attacks as it becomes harder for an attacker to turn a programming error into an exploitable security hole. The first implementation for Linux is 15 years old. Support in mainline kernel and toolchains have been available for a good while now. But to work, ASLR also needs executables to be built as position independent. And as Hanno Böck from the fuzzing project gently reminded me at 32C3, almost no executables in Debian are built as such, while it is now the default in Windows, Mac OS X, OpenBSD, and Fedora to name just a few other systems.

PIE has the reputation of having a performance hit. While true, especially for register constrained architectures like i386, it makes a difference only for the executable itself, not any shared library it uses as they are already built as position independent. Also, several optimizations have been made since the early days. GCC 5 will reuse the PIC hard register (which is also good for libraries). On amd64, GCC 5 and binutils 2.26 will do copy relocations. More improvements for i386 are being worked on.

I sincerly believe that users are way more likely to notice a compromised system than a slightly slower one.

Tracking progress

Since version 2.5.40, lintian will now issue a warning1 when it detects that a binary has not been compiled as a position independent executable. Kudos to Niels Thykier. Now that we can track our progress, I'm calling every Debian Developers: let's try to get as many ASLR-compatible executables in Stretch!

How to enable PIE

Thanks to all contributors over the past years who have improved our toolchain, we now have a fairly easy way to enable hardening flags with dpkg-buildflags. For packages using dh, it now boils down with adding on top of debian/rules:

export DEB_BUILD_MAINT_OPTIONS = hardening=+all

You can even test if a package supports all hardening flags without any changes running DEB_BUILD_OPTIONS=hardening=+all dpkg-buildpackage. Running lintian or hardening-check can then tell you if the protections have been successfully enabled.

Hardening by default?

But do we really need to change so many packages individually? The difference between the current default features and all hardening features are pie and bindnow. Could we turn them by default and do binNMUs instead of requiring actions from maintainers?

I guess the question boils down to: how many packages would require a (one-liner) change to turn off the pie or bindnow features if they were on by default?

To get the beginning of an answer, I took the top 502 (according to popcon installations) source packages shipping non-position independent executables. I've try to rebuild them enabling all hardening flags through DEB_BUILD_OPTIONS.

Out of 49 packages3:

  • 32 (65%) built fine and produced PIE binaries: acpi, bc, bind9, bsd-mailx, bsdmainutils, bzip2, cpio, cron, debianutils, diffutils, dpkg, file, fontconfig, gettext, glib2.0, glibc, gnupg, gzip, hostname, ifupdown, iputils, logrotate, m4, mutt, nano, net-tools, netcat, netkit-ftp, netkit-telnet, os-prober, pam, util-linux.
  • 4 (8%) built fine but did not compiled hardened binaries: discover, mawk, mlocate, patch.
  • 13 (27%) failed to build, with some of these expected failures, e.g. for *-static or GRUB: bash, busybox, coreutils, e2fsprogs, grub2, insserv, iptables, kbd, ncurses, newt, openssl, pciutils, perl.

The results are really encouraging. Especially taking in account that some of these packages are part of the “tricky and weird” set. To know for sure, we would need a mass-rebuild of the archive with DEB_BUILD_OPTIONS=hardening=+all in the environment. Any takers?

  1. Verification of the whole archive by the latest version of lintian is still in progress by the time I'm writing these lines. According to Niels it should take 3-4 more days to look at all available packages. ↩

  2. As always, UDD does wonders:

    SELECT packages.source, MAX(popcon.insts) AS insts FROM lintian, popcon, packages WHERE lintian.tag = 'hardening-no-pie' AND lintian.package_arch = 'amd64' AND popcon.package = lintian.package AND packages.package = popcon.package AND packages.distribution = 'debian' AND packages.release = 'sid' GROUP BY packages.source ORDER BY MAX(popcon.insts) DESC LIMIT 50;  ↩
  3. acpid currently fail to build from source in sid. ↩

Categories: Elsewhere

I Fix Drupal: I Have Enabled Page Caching But No Pages Are Getting Cached. Why?

Planet Drupal - Wed, 27/01/2016 - 08:52
Recently we received a call for help. The client had produced a new website that was great to look at, packed with fresh content and ready to launch. There was just one problem, performance. Some pages, in particular those driven by Views that were returning a large amount of data, were taking way too long to load. Interestingly the client had found that enabling page caching was not helping, yet enabling Views caching did help, a lot. This observation led us to believe that something was telling Drupal that it should not cache pages. So over an IRC session we asked the client to search their...
Categories: Elsewhere

Jonas Smedegaard: BOSS - Barath Operating System Solutions

Planet Debian - Wed, 27/01/2016 - 06:15

Siri and I are on a journey through India and Nepal, with the aim of learning about needs of Debian derivatives, to improve Debian and encourage closer integration.

C-DAC and BOSS

Centre for Development of Advanced Computing (C-DAC) is a large organization serving country- and state-level institutions in India, with offices and training facilities several major cities. In Chennai, C-DAC has a staff of 25 developers working full time on Barath Operating System Solutions (BOSS).

BOSS is a Debian derivative with several flavors - a desktop for use at primary schools (EduBOSS), a desktop for governmental offices (BOSS), and a range of server-oriented use cases using same core as the desktops with various (non-packaged) code and configuration on top.

The core common to all BOSS flavors is a derivative of Debian. Major work has been in strengthening localization and related code - including the development of a font covering all officially supported indic scripts, tuning input methods configuration, and bugfixing LibreOffice handling of complex scripts. All that work is all passed directly to upstream code projects (some still show as derived work until sifting down again into Debian).

Besides locale derivations, BOSS currently includes 11 packages not yet in Debian - a mixture of package dependencies, branding data and configuration tweaks. Seems most if not all can fit into Debian with a bit of restructuring work.

small computers

As some of you know, I always had a special interest in low-resource (yet general purpose) computers (partly driven by my lack of money to spend on shinier hardware), and since ~2009 particularly in ARM-based computers.

After 4 days of meetings and discussion with C-DAC, - literally few minutes before departure - I casually mentioned my interest in small computers, and much to my surprise it turned out that C-DAC also works on that, just didn't get around to mention it yet at the Debian wiki page.

C-DAC have worked for a year on tuning BOSS to work on the Vidyut laptop (successor to the Aakash tablet). All except builtin camera is allegedly working.

C-DAC is also looking into Olimex boards - my favorites - possibly for use with small server setups…

…but our time was up, we had to leave for our train to Pune, so details on that we will have to figure out through mail.

collaboration

In the past, C-DAC have kept in touch with their users through BOSS-specific places like a dedicated IRC channel. Recent changes in management style at the development office have caused less attention available to that communication, however.

C-DAC have politely offered their code changes upstram for years, but maybe "too polite": Maybe they have offered only polished fixes, being less loud about "interesting problems".

I suggested, as way to improve while limiting (ideally avoiding) extra work, is to mentally take a step up the stream: Treat BOSS not as a derivative but a subset of Debian itself, hang out and discuss issues and ideas at debian irc channels, and maintain your packages directly in Debian.

Only parts unfit for Debian - secret stuff done for India military, and dirty configuration hacks not yet possible within Debian Policy - really need to be kept away from Debian.

C-DAC agreed, and Debian now has a BOSS team!

Anyone interested to follow BOSS as a Debian blend, and perhaps even contribute with opinions and/or code, is quite welcome to join the newly created mailinglist on Debian Alioth: https://lists.alioth.debian.org/mailman/listinfo/boss-devel.

Our meetings with BOSS developers have been very pleasant. Even those working at the top of cloud or big data stacks - furthest away from our mindset of tightly "locking down" all parts as packages - were patient with us.

Thanks in particular to Prema S and Prathibha B, working on packaging of BOSS for the past 5+ years, and both likely to enter the Debian New Maintainer Queue before long

Categories: Elsewhere

DrupalCon News: Announcing the DrupalCon Asia Developer Contest

Planet Drupal - Wed, 27/01/2016 - 04:52

Vroom vroom! Love Adventure? Love Drupal? Want to win a Royal Enfield Classic motorcycle? You're in luck!

The DrupalCon Asia Developer Contest is being sponsored by the great folks over at Azri Solutions and they've come up with one of the coolest developer contests we've heard of thus far. The challenge, should you choose to accept it, is this: create a beautiful, interactive visualization of the data found at https://www.drupal.org/drupalorg/api, and submit it via github no later than 11:59 PM IST on Thursday, February 18.

Categories: Elsewhere

ActiveLAMP: PSR-4 Class Autoloading with Drupal 7

Planet Drupal - Wed, 27/01/2016 - 04:00
You don't have to wait for Drupal 8 to start using PSR-4 namespaces. In this video, watch as we write a Views handler in a Drupal 7 module using the PSR-4 standard. Also, if you've never seen "Drush Quick Drupal" in action, watch how quickly a new Drupal site is spun up locally with the exact modules needed, downloaded and enabled by executing one Drush command, `drush qd`. Lots of hidden gems in this video, leave us a comment if you saw something you liked!
Categories: Elsewhere

Lunar: ALSR now!

Planet Debian - Wed, 27/01/2016 - 01:46

Address space layout randomization helps to protect against buffer overflow attacks as it becomes harder for an attacker to turn a programming error into an exploitable security hole. The first implementation for Linux is 15 years old. Support in mainline kernel and toolchains have been available for a good while now. But to work, ASLR also needs executables to be built as position independent. And as Hanno Böck from the fuzzing project gently reminded me at 32C3, almost no executables in Debian are built as such, while it is now the default in Windows, Mac OS X, OpenBSD, and Fedora to name just a few other systems.

PIE has the reputation of having a performance hit. While true, especially for register constrained architectures like i386, it makes a difference only for the executable itself, not any shared library it uses as they are already built as position independent. Also, several optimizations have been made since the early days. GCC 5 will reuse the PIC hard register (which is also good for libraries). On amd64, GCC 5 and binutils 2.26 will do copy relocations. More improvements for i386 are being worked on.

I sincerly believe that users are way more likely to notice a compromised system than a slightly slower one.

Tracking progress

Since version 2.5.40, lintian will now issue a warning1 when it detects that a binary has not been compiled as a position independent executable. Kudos to Niels Thykier. Now that we can track our progress, I'm calling every Debian Developers: let's try to get as many ALSR-compatible executables in Stretch!

How to enable PIE

Thanks to all contributors over the past years who have improved our toolchain, we now have a fairly easy way to enable hardening flags with dpkg-buildflags. For packages using dh, it now boils down with adding on top of debian/rules:

export DEB_BUILD_MAINT_OPTIONS = hardening=+all

You can even test if a package supports all hardening flags without any changes running DEB_BUILD_OPTIONS=hardening=+all dpkg-buildpackage. Running lintian or hardening-check can then tell you if the protections have been successfully enabled.

Hardening by default?

But do we really need to change so many packages individually? The difference between the current default features and all hardening features are pie and bindnow. Could we turn them by default and do binNMUs instead of requiring actions from maintainers?

I guess the question boils down to: how many packages would require a (one-liner) change to turn off the pie or bindnow features if they were on by default?

To get the beginning of an answer, I took the top 502 (according to popcon installations) source packages shipping non-position independent executables. I've try to rebuild them enabling all hardening flags through DEB_BUILD_OPTIONS.

Out of 49 packages3:

  • 32 (65%) built fine and produced PIE binaries: acpi, bc, bind9, bsd-mailx, bsdmainutils, bzip2, cpio, cron, debianutils, diffutils, dpkg, file, fontconfig, gettext, glib2.0, glibc, gnupg, gzip, hostname, ifupdown, iputils, logrotate, m4, mutt, nano, net-tools, netcat, netkit-ftp, netkit-telnet, os-prober, pam, util-linux.
  • 4 (8%) built fine but did not compiled hardened binaries: discover, mawk, mlocate, patch.
  • 13 (27%) failed to build, with some of these expected failures, e.g. for *-static or GRUB: bash, busybox, coreutils, e2fsprogs, grub2, insserv, iptables, kbd, ncurses, newt, openssl, pciutils, perl.

The results are really encouraging. Especially taking in account that some of these packages are part of the “tricky and weird” set. To know for sure, we would need a mass-rebuild of the archive with DEB_BUILD_OPTIONS=hardening=+all in the environment. Any takers?

  1. Verification of the whole archive by the latest version of lintian is still in progress by the time I'm writing these lines. According to Niels it should take 3-4 more days to look at all available packages. ↩

  2. As always, UDD does wonders:

    SELECT packages.source, MAX(popcon.insts) AS insts FROM lintian, popcon, packages WHERE lintian.tag = 'hardening-no-pie' AND lintian.package_arch = 'amd64' AND popcon.package = lintian.package AND packages.package = popcon.package AND packages.distribution = 'debian' AND packages.release = 'sid' GROUP BY packages.source ORDER BY MAX(popcon.insts) DESC LIMIT 50;  ↩
  3. acpid currently fail to build from source in sid. ↩

Categories: Elsewhere

OSTraining: Video: Train Your Staff for Drupal 8

Planet Drupal - Wed, 27/01/2016 - 00:01

In mid-January we held a webinar with Acquia, explaining how to train your team on Drupal 8.

This was an interesting webinar to run because it ended up being pretty different from our planning. There were two major changes:

  1. When scheduling the webinar, we intended to explain many of Drupal 8 training resources available. However, by mid-January, many contributed Drupal 8 modules didn't have stable releases and so most D8 training wasn't ready. So, in the webinar, we explaind when Drupal 8 training would be available.
  2. We were able to make a very cool surprise announcement. Watch to the end of the webinar for the big reveal.

From the webinar, here's an overview of when several important modules will be stable:

Categories: Elsewhere

Pages

Subscribe to jfhovinne aggregator