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

Lullabot: One Year of Backdrop CMS with Jen & Nate

Planet Drupal - Tue, 26/01/2016 - 23:44
Matt & Mike talk with Backdrop CMS founding forkers Jen Lampton & Nate Haug about Backdrop now that Drupal 8 is released.
Categories: Elsewhere

Palantir: Web Services in Drupal 8

Planet Drupal - Tue, 26/01/2016 - 18:30

Web Services in today's applications and websites have become critical to interacting with third parties, and a lot of Drupal developers have the need to expose content and features on their site via an API. Luckily for us, Drupal 8 now has this capability built right into Core. Some contrib modules are attempting to make such capabilities even better, too.

To shed some light onto these new features, we've worked with Acquia to develop a webinar and subsequent series of blog posts to help get you up to speed with these exciting, new features. The first of these blog posts, Web Services 101, has been published on the Acquia Developer Center today, written by our very own Senior Architect and Community Lead Larry "Crell" Garfield.

Larry kicks off the series by laying out a comprehensive explanation of exactly what Web services are, providing a necessary and strong foundation for you to approach the exciting Web services developments new to Drupal 8. Look for his follow-up posts on Palantir.net in the coming weeks. And in the meantime, we have plenty more Drupal 8 content with Larry's .

This first post on Acquia is part of a 4-part series written by Larry, and Kyle Browning, of Acquia, based on a webinar that Larry and Kyle recently gave: Drupal 8 Deep Dive: What It Means for Developers Now that REST Is in Core.

Categories: Elsewhere

Pages

Subscribe to jfhovinne aggregator - Elsewhere