Tag Archives: firefox

Security updates for Thursday

Post Syndicated from ris original https://lwn.net/Articles/744075/rss

Security updates have been issued by Arch Linux (glibc and lib32-glibc), Debian (ming and poco), Fedora (electron-cash, electrum, firefox, heketi, microcode_ctl, and python-jsonrpclib), openSUSE (clamav-database and ucode-intel), Red Hat (flash-plugin), SUSE (OBS toolchain), and Ubuntu (webkit2gtk).

Security updates for Monday

Post Syndicated from ris original https://lwn.net/Articles/743575/rss

Security updates have been issued by Arch Linux (linux-hardened, linux-lts, linux-zen, and mongodb), Debian (gdk-pixbuf, gifsicle, graphicsmagick, kernel, and poppler), Fedora (dracut, electron-cash, and firefox), Gentoo (backintime, binutils, chromium, emacs, libXcursor, miniupnpc, openssh, optipng, and webkit-gtk), Mageia (kernel, kernel-linus, kernel-tmb, openafs, and python-mistune), openSUSE (clamav-database, ImageMagick, kernel-firmware, nodejs4, and qemu), Red Hat (linux-firmware, ovirt-guest-agent-docker, qemu-kvm-rhev, redhat-virtualization-host, rhev-hypervisor7, rhvm-appliance, thunderbird, and vdsm), Scientific Linux (thunderbird), SUSE (kernel and qemu), and Ubuntu (firefox and poppler).

Security updates for Wednesday

Post Syndicated from ris original https://lwn.net/Articles/742671/rss

Security updates have been issued by Debian (poppler), Fedora (glibc, phpMyAdmin, python33, and xen), Mageia (awstats, binutils, connman, elfutils, fontforge, fossil, gdb, gimp, jbig2dec, libextractor, libical, libplist, mbedtls, mercurial, OpenEXR, openldap, perl-DBD-mysql, podofo, python-werkzeug, raptor2, rkhunter, samba, w3m, and wayland), and Ubuntu (firefox).

Massive Site-Blocking Measures Countered By 100K Browser Addon Users

Post Syndicated from Andy original https://torrentfreak.com/massive-site-blocking-measures-countered-by-100k-browser-addon-users-171231/

FCT tyIn July 2015, Portugal’s Ministry of Culture announced the signing of a memorandum between its own General Inspection of Cultural Activities (IGAC), the Portuguese Association of Telecommunication Operators (APRITEL), various rightsholder groups, the body responsible for administering Portugal’s .PT domain, and representatives from the advertising industry.

The memorandum laid out a new mechanism for blocking so-called ‘pirate’ sites. In common with similar frameworks elsewhere, the process can be triggered by a complaint from a rightsholder association. Local anti-piracy group MAPINET then collates evidence that a site is engaged in the unlawful distribution of copyright works and has failed to cease its activities.

The system was quickly utilized by rightsholders seeking to block access to their content. Within six months, 330 sites had been blocked by ISPs, but that was only the beginning. In the months and years that followed, hundreds more sites were rendered inaccessible but in common with similar programs elsewhere, no official list of blocked sites was made available. People are keeping watch, however.

SitesBloqueados (Blocked Sites) is a web portal run by Revolução dos Bytes (Bytes’ Revolution), a group of like-minded anti-censorship activists in Portugal. Created a few months after blocking began in the region, their comprehensive database now contains almost 1,400 domains, the majority of which have been blocked on copyright grounds.

“SitesBloqueados was mainly created because, although the Memorandum of Understanding contained certain requirements to make a site eligible to be blocked – such as 500 items [or links] to copyright content or one third of the site containing copyrighted material – there was no official way to validate that data and make sure that these ‘rules’ are being respected,” team member Henrique Mouta informs TF.

The manner in which the list is maintained is quite unique. As mentioned earlier, there are no official sources listing blocked domains so the people behind SitesBloqueados had to get creative. Alongside this project they also run Ahoy!, a Chrome and Firefox extension that allows users to circumvent censorship in Portugal and it’s through that tool they gather information.

“Ahoy! basically bypasses any traffic to a blocked site through our own proxies, allowing the users to navigate in a free, uncensored internet,” Henrique explains.

As this extension works on a whitelist basis, we had to create a mechanism to automatically detect and whitelist sites that have been blocked, so if a user accesses a blocked site that is not on our list yet, we get a notification so we can review the site and add it to the list. That is the list that is also powering SitesBloqueados.pt.”

When the voluntary agreement was first announced, local ISPs came under intense criticism for agreeing to work with copyright holders without need for a court process. However, Henrique says they are actually in a precarious position.

“We usually see the ISPs as the bad guys, blocking sites, throttling our internet and, more recently, going against the Internet Neutrality. But, in this particular case, all the major ISPs are forced to block any sites that have been requested in 15 days, or they might pay fines for every single day after the deadline.

“MAPiNET (MOVIMENTO CÍVICOANTI PIRATARIA NA INTERNET) is the organization, alongside with IGAC (Inspecção Geral Das Actividades Culturais), that compiles the lists of sites and sends them to the ISP. It’s usually two lists per month. Of course, I’m not excusing the ISPs, as they should stand up against censorship. But we all know that’s asking too much of them,” Henrique adds.

Interestingly, the first site blockade in Portugal wasn’t actioned on copyright grounds. It was, in fact, targeted at Uber.com.

“This happened in June 2015, after a court order to suspend all Uber activity in Portugal. This opened a huge precedent, with all these anti-piracy organizations seeing how easy is to block a site, technically speaking.

“So, at the end of August of that same year, the [anti-piracy] Memorandum was signed by all the parties and, since then, both MAPiNET and IGAC have the power to request any site block, without any court order, without any legal order,” Henrique notes.

This lit a fire under the team and two and half years later, Ahoy! is now being used by 100k people to unblock almost 1,400 sites, while feeding back information on newly blocked domains. These are then added to the blocklist database and considered for unblocking methods via the addon.

Currently, around 50 new domains are blocked every month in Portugal and Henrique and the team are determined to document every one of them. They believe that by keeping an eye on things publicly, it lets the anti-piracy groups know they are being watched and cannot act with impunity. Around 90% of all blocked domains are restricted on copyright grounds but some also fall foul of new gambling laws that forbid unlicensed sites.

From the beginning, the big question has surrounded potential abuse. So, given the lack of a court process, have any players attempted to game the system?

“So far, we haven’t seen any signs of intentional abuse. There have been a few problems with sites being wrongly blocked. The most popular case is Carbon Games site that was blocked nearly two years ago, and it was mistaken for a different site, a Gambling site, named Carbon Gaming,” Henrique says.

“A few months later, we detected another case. A Spanish journalist had a website where he was posting videoclips of the latest releases. All of these releases were originally on YouTube, uploaded by the respective owners, however that was not enough to keep the site alive.”

Under pressure from Revolução dos Bytes this block was reversed but it’s not the only instance of errors. Non-existent sites have been blocked as have sites publishing headlines and linking to the respective online newspapers.

With blocking continuing at a steady pace, dozens of new domains are restricted every month. But Henrique and the team believe it won’t achieve anything positive and only serves to harm the Internet and democracy.

“Blocking sites to prevent piracy is the same as being on a sinking submarine, trying to patch every leaking hull hole with duct tape. If they want to fight piracy, they should try to understand, in the first place, why it happens and what they can do to change it.

“It’s well known that having cheap and quality services like Netflix and Spotify helped Internet piracy levels drop to record lows, DRM issues aside, of course. And the worst of it is the timing: these organizations see the decreasing levels of piracy as a signal that their stupid censorship is actually working. I’m really afraid that this is now an unstoppable snowball. The Internet in Portugal has seen much better days,” Henrique concludes.

But while he’s pessimistic over current developments, it appears that the Ahoy! movement is only set to grow. The team say they want to bring the browser-based system to other countries that are suffering from similar blockades and that suggestions from the public are welcome.

Source: TF, for the latest info on copyright, file-sharing, torrent sites and more. We also have VPN discounts, offers and coupons

Security updates for Tuesday

Post Syndicated from ris original https://lwn.net/Articles/741257/rss

Security updates have been issued by Debian (chromium-browser, evince, pdns-recursor, and simplesamlphp), Fedora (ceph, dhcp, erlang, exim, fedora-arm-installer, firefox, libvirt, openssh, pdns-recursor, rubygem-yard, thunderbird, wordpress, and xen), Red Hat (rh-mysql57-mysql), SUSE (kernel), and Ubuntu (openssl).

Security updates for Monday

Post Syndicated from ris original https://lwn.net/Articles/741158/rss

Security updates have been issued by CentOS (postgresql), Debian (firefox-esr, kernel, libxcursor, optipng, thunderbird, wireshark, and xrdp), Fedora (borgbackup, ca-certificates, collectd, couchdb, curl, docker, erlang-jiffy, fedora-arm-installer, firefox, git, linux-firmware, mupdf, openssh, thunderbird, transfig, wildmidi, wireshark, xen, and xrdp), Mageia (firefox and optipng), openSUSE (erlang, libXfont, and OBS toolchain), Oracle (kernel), Slackware (openssl), and SUSE (kernel and OBS toolchain).

Security updates for Friday

Post Syndicated from jake original https://lwn.net/Articles/740997/rss

Security updates have been issued by Arch Linux (chromium and vlc), Debian (erlang), Mageia (ffmpeg, tor, and wireshark), openSUSE (chromium, opensaml, openssh, openvswitch, and php7), Oracle (postgresql), Red Hat (chromium-browser, postgresql, rh-postgresql94-postgresql, rh-postgresql95-postgresql, and rh-postgresql96-postgresql), SUSE (firefox, java-1_6_0-ibm, opensaml, and xen), and Ubuntu (kernel, linux, linux-aws, linux-kvm, linux-raspi2, linux-snapdragon, linux, linux-raspi2, linux-azure, linux-gcp, linux-hwe, linux-lts-trusty, linux-lts-xenial, linux-aws, and rsync).

Security updates for Thursday

Post Syndicated from jake original https://lwn.net/Articles/740883/rss

Security updates have been issued by CentOS (firefox, java-1.7.0-openjdk, kernel, liblouis, qemu-kvm, sssd, and thunderbird), Debian (heimdal and nova), openSUSE (shibboleth-sp), Oracle (java-1.7.0-openjdk), Red Hat (Red Hat OpenShift Enterprise), Scientific Linux (openafs), SUSE (kernel), and Ubuntu (rsync).

Looking Forward to 2018

Post Syndicated from Let's Encrypt - Free SSL/TLS Certificates original https://letsencrypt.org//2017/12/07/looking-forward-to-2018.html

Let’s Encrypt had a great year in 2017. We more than doubled the number of active (unexpired) certificates we service to 46 million, we just about tripled the number of unique domains we service to 61 million, and we did it all while maintaining a stellar security and compliance track record. Most importantly though, the Web went from 46% encrypted page loads to 67% according to statistics from Mozilla – a gain of 21% in a single year – incredible. We’re proud to have contributed to that, and we’d like to thank all of the other people and organizations who also worked hard to create a more secure and privacy-respecting Web.

While we’re proud of what we accomplished in 2017, we are spending most of the final quarter of the year looking forward rather than back. As we wrap up our own planning process for 2018, I’d like to share some of our plans with you, including both the things we’re excited about and the challenges we’ll face. We’ll cover service growth, new features, infrastructure, and finances.

Service Growth

We are planning to double the number of active certificates and unique domains we service in 2018, to 90 million and 120 million, respectively. This anticipated growth is due to continuing high expectations for HTTPS growth in general in 2018.

Let’s Encrypt helps to drive HTTPS adoption by offering a free, easy to use, and globally available option for obtaining the certificates required to enable HTTPS. HTTPS adoption on the Web took off at an unprecedented rate from the day Let’s Encrypt launched to the public.

One of the reasons Let’s Encrypt is so easy to use is that our community has done great work making client software that works well for a wide variety of platforms. We’d like to thank everyone involved in the development of over 60 client software options for Let’s Encrypt. We’re particularly excited that support for the ACME protocol and Let’s Encrypt is being added to the Apache httpd server.

Other organizations and communities are also doing great work to promote HTTPS adoption, and thus stimulate demand for our services. For example, browsers are starting to make their users more aware of the risks associated with unencrypted HTTP (e.g. Firefox, Chrome). Many hosting providers and CDNs are making it easier than ever for all of their customers to use HTTPS. Government agencies are waking up to the need for stronger security to protect constituents. The media community is working to Secure the News.

New Features

We’ve got some exciting features planned for 2018.

First, we’re planning to introduce an ACME v2 protocol API endpoint and support for wildcard certificates along with it. Wildcard certificates will be free and available globally just like our other certificates. We are planning to have a public test API endpoint up by January 4, and we’ve set a date for the full launch: Tuesday, February 27.

Later in 2018 we plan to introduce ECDSA root and intermediate certificates. ECDSA is generally considered to be the future of digital signature algorithms on the Web due to the fact that it is more efficient than RSA. Let’s Encrypt will currently sign ECDSA keys from subscribers, but we sign with the RSA key from one of our intermediate certificates. Once we have an ECDSA root and intermediates, our subscribers will be able to deploy certificate chains which are entirely ECDSA.

Infrastructure

Our CA infrastructure is capable of issuing millions of certificates per day with multiple redundancy for stability and a wide variety of security safeguards, both physical and logical. Our infrastructure also generates and signs nearly 20 million OCSP responses daily, and serves those responses nearly 2 billion times per day. We expect issuance and OCSP numbers to double in 2018.

Our physical CA infrastructure currently occupies approximately 70 units of rack space, split between two datacenters, consisting primarily of compute servers, storage, HSMs, switches, and firewalls.

When we issue more certificates it puts the most stress on storage for our databases. We regularly invest in more and faster storage for our database servers, and that will continue in 2018.

We’ll need to add a few additional compute servers in 2018, and we’ll also start aging out hardware in 2018 for the first time since we launched. We’ll age out about ten 2u compute servers and replace them with new 1u servers, which will save space and be more energy efficient while providing better reliability and performance.

We’ll also add another infrastructure operations staff member, bringing that team to a total of six people. This is necessary in order to make sure we can keep up with demand while maintaining a high standard for security and compliance. Infrastructure operations staff are systems administrators responsible for building and maintaining all physical and logical CA infrastructure. The team also manages a 24/7/365 on-call schedule and they are primary participants in both security and compliance audits.

Finances

We pride ourselves on being an efficient organization. In 2018 Let’s Encrypt will secure a large portion of the Web with a budget of only $3.0M. For an overall increase in our budget of only 13%, we will be able to issue and service twice as many certificates as we did in 2017. We believe this represents an incredible value and that contributing to Let’s Encrypt is one of the most effective ways to help create a more secure and privacy-respecting Web.

Our 2018 fundraising efforts are off to a strong start with Platinum sponsorships from Mozilla, Akamai, OVH, Cisco, Google Chrome and the Electronic Frontier Foundation. The Ford Foundation has renewed their grant to Let’s Encrypt as well. We are seeking additional sponsorship and grant assistance to meet our full needs for 2018.

We had originally budgeted $2.91M for 2017 but we’ll likely come in under budget for the year at around $2.65M. The difference between our 2017 expenses of $2.65M and the 2018 budget of $3.0M consists primarily of the additional infrastructure operations costs previously mentioned.

Support Let’s Encrypt

We depend on contributions from our community of users and supporters in order to provide our services. If your company or organization would like to sponsor Let’s Encrypt please email us at [email protected]. We ask that you make an individual contribution if it is within your means.

We’re grateful for the industry and community support that we receive, and we look forward to continuing to create a more secure and privacy-respecting Web!

Security updates for Wednesday

Post Syndicated from ris original https://lwn.net/Articles/740799/rss

Security updates have been issued by CentOS (samba4), Mageia (libxcursor and libxfont/libxfont2), openSUSE (exim, GraphicsMagick, graphviz, pdns, and pdns-recursor), Oracle (firefox and liblouis), Red Hat (java-1.7.0-openjdk), Scientific Linux (java-1.7.0-openjdk), SUSE (firefox, shibboleth-sp, and xen), and Ubuntu (linux-firmware).

Security updates for Tuesday

Post Syndicated from ris original https://lwn.net/Articles/740721/rss

Security updates have been issued by Debian (libextractor), Fedora (java-9-openjdk, kernel, python, and qt5-qtwebengine), Oracle (sssd and thunderbird), Red Hat (firefox, liblouis, and sssd), Scientific Linux (firefox, liblouis, and sssd), and Ubuntu (libxml2).

Security updates for Monday

Post Syndicated from ris original https://lwn.net/Articles/740605/rss

Security updates have been issued by Arch Linux (cacti, curl, exim, lib32-curl, lib32-libcurl-compat, lib32-libcurl-gnutls, lib32-libxcursor, libcurl-compat, libcurl-gnutls, libofx, libxcursor, procmail, samba, shadowsocks-libev, and thunderbird), Debian (tor), Fedora (kernel, moodle, mupdf, python-sanic, qbittorrent, qpid-cpp, and rb_libtorrent), Mageia (git, lame, memcached, nagios, perl-Catalyst-Plugin-Static-Simple, php-phpmailer, shadowsocks-libev, and varnish), openSUSE (binutils, libressl, lynx, openssl, tor, wireshark, and xen), Red Hat (thunderbird), Scientific Linux (kernel, qemu-kvm, and thunderbird), SUSE (kernel, ncurses, openvpn-openssl1, and xen), and Ubuntu (curl, evince, and firefox).

Security updates for Tuesday

Post Syndicated from ris original https://lwn.net/Articles/740133/rss

Security updates have been issued by Arch Linux (powerdns and powerdns-recursor), CentOS (curl and samba), Debian (ffmpeg and roundcube), Fedora (cacti and samba), openSUSE (thunderbird), Oracle (curl), Red Hat (java-1.8.0-ibm and rh-mysql56-mysql), Scientific Linux (curl), Slackware (samba), SUSE (kernel-firmware and samba), and Ubuntu (exim4, firefox, libxml-libxml-perl, optipng, and postgresql-common).

UI Testing at Scale with AWS Lambda

Post Syndicated from Stas Neyman original https://aws.amazon.com/blogs/devops/ui-testing-at-scale-with-aws-lambda/

This is a guest blog post by Wes Couch and Kurt Waechter from the Blackboard Internal Product Development team about their experience using AWS Lambda.

One year ago, one of our UI test suites took hours to run. Last month, it took 16 minutes. Today, it takes 39 seconds. Here’s how we did it.

The backstory:

Blackboard is a global leader in delivering robust and innovative education software and services to clients in higher education, government, K12, and corporate training. We have a large product development team working across the globe in at least 10 different time zones, with an internal tools team providing support for quality and workflows. We have been using Selenium Webdriver to perform automated cross-browser UI testing since 2007. Because we are now practicing continuous delivery, the automated UI testing challenge has grown due to the faster release schedule. On top of that, every commit made to each branch triggers an execution of our automated UI test suite. If you have ever implemented an automated UI testing infrastructure, you know that it can be very challenging to scale and maintain. Although there are services that are useful for testing different browser/OS combinations, they don’t meet our scale needs.

It used to take three hours to synchronously run our functional UI suite, which revealed the obvious need for parallel execution. Previously, we used Mesos to orchestrate a Selenium Grid Docker container for each test run. This way, we were able to run eight concurrent threads for test execution, which took an average of 16 minutes. Although this setup is fine for a single workflow, the cracks started to show when we reached the scale required for Blackboard’s mature product lines. Going beyond eight concurrent sessions on a single container introduced performance problems that impact the reliability of tests (for example, issues in Webdriver or the browser popping up frequently). We tried Mesos and considered Kubernetes for Selenium Grid orchestration, but the answer to scaling a Selenium Grid was to think smaller, not larger. This led to our breakthrough with AWS Lambda.

The solution:

We started using AWS Lambda for UI testing because it doesn’t require costly infrastructure or countless man hours to maintain. The steps we outline in this blog post took one work day, from inception to implementation. By simply packaging the UI test suite into a Lambda function, we can execute these tests in parallel on a massive scale. We use a custom JUnit test runner that invokes the Lambda function with a request to run each test from the suite. The runner then aggregates the results returned from each Lambda test execution.

Selenium is the industry standard for testing UI at scale. Although there are other options to achieve the same thing in Lambda, we chose this mature suite of tools. Selenium is backed by Google, Firefox, and others to help the industry drive their browsers with code. This makes Lambda and Selenium a compelling stack for achieving UI testing at scale.

Making Chrome Run in Lambda

Currently, Chrome for Linux will not run in Lambda due to an absent mount point. By rebuilding Chrome with a slight modification, as Marco Lüthy originally demonstrated, you can run it inside Lambda anyway! It took about two hours to build the current master branch of Chromium to build on a c4.4xlarge. Unfortunately, the current version of ChromeDriver, 2.33, does not support any version of Chrome above 62, so we’ll be using Marco’s modified version of version 60 for the near future.

Required System Libraries

The Lambda runtime environment comes with a subset of common shared libraries. This means we need to include some extra libraries to get Chrome and ChromeDriver to work. Anything that exists in the java resources folder during compile time is included in the base directory of the compiled jar file. When this jar file is deployed to Lambda, it is placed in the /var/task/ directory. This allows us to simply place the libraries in the java resources folder under a folder named lib/ so they are right where they need to be when the Lambda function is invoked.

To get these libraries, create an EC2 instance and choose the Amazon Linux AMI.

Next, use ssh to connect to the server. After you connect to the new instance, search for the libraries to find their locations.

sudo find / -name libgconf-2.so.4
sudo find / -name libORBit-2.so.0

Now that you have the locations of the libraries, copy these files from the EC2 instance and place them in the java resources folder under lib/.

Packaging the Tests

To deploy the test suite to Lambda, we used a simple Gradle tool called ShadowJar, which is similar to the Maven Shade Plugin. It packages the libraries and dependencies inside the jar that is built. Usually test dependencies and sources aren’t included in a jar, but for this instance we want to include them. To include the test dependencies, add this section to the build.gradle file.

shadowJar {
   from sourceSets.test.output
   configurations = [project.configurations.testRuntime]
}

Deploying the Test Suite

Now that our tests are packaged with the dependencies in a jar, we need to get them into a running Lambda function. We use  simple SAM  templates to upload the packaged jar into S3, and then deploy it to Lambda with our settings.

{
   "AWSTemplateFormatVersion": "2010-09-09",
   "Transform": "AWS::Serverless-2016-10-31",
   "Resources": {
       "LambdaTestHandler": {
           "Type": "AWS::Serverless::Function",
           "Properties": {
               "CodeUri": "./build/libs/your-test-jar-all.jar",
               "Runtime": "java8",
               "Handler": "com.example.LambdaTestHandler::handleRequest",
               "Role": "<YourLambdaRoleArn>",
               "Timeout": 300,
               "MemorySize": 1536
           }
       }
   }
}

We use the maximum timeout available to ensure our tests have plenty of time to run. We also use the maximum memory size because this ensures our Lambda function can support Chrome and other resources required to run a UI test.

Specifying the handler is important because this class executes the desired test. The test handler should be able to receive a test class and method. With this information it will then execute the test and respond with the results.

public LambdaTestResult handleRequest(TestRequest testRequest, Context context) {
   LoggerContainer.LOGGER = new Logger(context.getLogger());
  
   BlockJUnit4ClassRunner runner = getRunnerForSingleTest(testRequest);
  
   Result result = new JUnitCore().run(runner);

   return new LambdaTestResult(result);
}

Creating a Lambda-Compatible ChromeDriver

We provide developers with an easily accessible ChromeDriver for local test writing and debugging. When we are running tests on AWS, we have configured ChromeDriver to run them in Lambda.

To configure ChromeDriver, we first need to tell ChromeDriver where to find the Chrome binary. Because we know that ChromeDriver is going to be unzipped into the root task directory, we should point the ChromeDriver configuration at that location.

The settings for getting ChromeDriver running are mostly related to Chrome, which must have its working directories pointed at the tmp/ folder.

Start with the default DesiredCapabilities for ChromeDriver, and then add the following settings to enable your ChromeDriver to start in Lambda.

public ChromeDriver createLambdaChromeDriver() {
   ChromeOptions options = new ChromeOptions();

   // Set the location of the chrome binary from the resources folder
   options.setBinary("/var/task/chrome");

   // Include these settings to allow Chrome to run in Lambda
   options.addArguments("--disable-gpu");
   options.addArguments("--headless");
   options.addArguments("--window-size=1366,768");
   options.addArguments("--single-process");
   options.addArguments("--no-sandbox");
   options.addArguments("--user-data-dir=/tmp/user-data");
   options.addArguments("--data-path=/tmp/data-path");
   options.addArguments("--homedir=/tmp");
   options.addArguments("--disk-cache-dir=/tmp/cache-dir");
  
   DesiredCapabilities desiredCapabilities = DesiredCapabilities.chrome();
   desiredCapabilities.setCapability(ChromeOptions.CAPABILITY, options);
  
   return new ChromeDriver(desiredCapabilities);
}

Executing Tests in Parallel

You can approach parallel test execution in Lambda in many different ways. Your approach depends on the structure and design of your test suite. For our solution, we implemented a custom test runner that uses reflection and JUnit libraries to create a list of test cases we want run. When we have the list, we create a TestRequest object to pass into the Lambda function that we have deployed. In this TestRequest, we place the class name, test method, and the test run identifier. When the Lambda function receives this TestRequest, our LambdaTestHandler generates and runs the JUnit test. After the test is complete, the test result is sent to the test runner. The test runner compiles a result after all of the tests are complete. By executing the same Lambda function multiple times with different test requests, we can effectively run the entire test suite in parallel.

To get screenshots and other test data, we pipe those files during test execution to an S3 bucket under the test run identifier prefix. When the tests are complete, we link the files to each test execution in the report generated from the test run. This lets us easily investigate test executions.

Pro Tip: Dynamically Loading Binaries

AWS Lambda has a limit of 250 MB of uncompressed space for packaged Lambda functions. Because we have libraries and other dependencies to our test suite, we hit this limit when we tried to upload a function that contained Chrome and ChromeDriver (~140 MB). This test suite was not originally intended to be used with Lambda. Otherwise, we would have scrutinized some of the included libraries. To get around this limit, we used the Lambda functions temporary directory, which allows up to 500 MB of space at runtime. Downloading these binaries at runtime moves some of that space requirement into the temporary directory. This allows more room for libraries and dependencies. You can do this by grabbing Chrome and ChromeDriver from an S3 bucket and marking them as executable using built-in Java libraries. If you take this route, be sure to point to the new location for these executables in order to create a ChromeDriver.

private static void downloadS3ObjectToExecutableFile(String key) throws IOException {
   File file = new File("/tmp/" + key);

   GetObjectRequest request = new GetObjectRequest("s3-bucket-name", key);

   FileUtils.copyInputStreamToFile(s3client.getObject(request).getObjectContent(), file);
   file.setExecutable(true);
}

Lambda-Selenium Project Source

We have compiled an open source example that you can grab from the Blackboard Github repository. Grab the code and try it out!

https://blackboard.github.io/lambda-selenium/

Conclusion

One year ago, one of our UI test suites took hours to run. Last month, it took 16 minutes. Today, it takes 39 seconds. Thanks to AWS Lambda, we can reduce our build times and perform automated UI testing at scale!

Security updates for Monday

Post Syndicated from ris original https://lwn.net/Articles/739648/rss

Security updates have been issued by Arch Linux (icu and lib32-icu), CentOS (firefox), Debian (imagemagick, konversation, libspring-ldap-java, libxml-libxml-perl, lynx-cur, ming, opensaml2, poppler, procmail, shibboleth-sp2, and xen), Fedora (firefox, java-9-openjdk, jbig2dec, kernel, knot, knot-resolver, qt5-qtwebengine, and roundcubemail), Gentoo (adobe-flash, couchdb, icedtea-bin, and phpunit), Mageia (apr, bluez, firefox, jq, konversation, libextractor, and quagga), Oracle (firefox), Red Hat (firefox), and Scientific Linux (firefox).

Security updates for Thursday

Post Syndicated from jake original https://lwn.net/Articles/739318/rss

Security updates have been issued by Arch Linux (firefox, flashplugin, lib32-flashplugin, and mediawiki), CentOS (kernel and php), Debian (firefox-esr, jackson-databind, and mediawiki), Fedora (apr, apr-util, chromium, compat-openssl10, firefox, ghostscript, hostapd, icu, ImageMagick, jackson-databind, krb5, lame, liblouis, nagios, nodejs, perl-Catalyst-Plugin-Static-Simple, php, php-PHPMailer, poppler, poppler-data, rubygem-ox, systemd, webkitgtk4, wget, wordpress, and xen), Mageia (flash-player-plugin, icu, jackson-databind, php, and roundcubemail), Oracle (kernel and php), Red Hat (openstack-aodh), SUSE (wget and xen), and Ubuntu (apport and webkit2gtk).

Firefox 57

Post Syndicated from ris original https://lwn.net/Articles/738996/rss

Firefox 57 has been released. From the release
notes
: “Brace yourself for an all-new Firefox. It’s fast. Really
fast. It’s over twice as fast as Firefox from 6 months ago, built on a
completely overhauled core engine with brand new technology from our
advanced research group, and graced with a clean, modern interface. Today
is the first of several releases we’re calling Firefox Quantum, all
designed to get to the things you love and the stuff you need faster than
ever before. Experience the difference on desktops running Windows, macOS,
and Linux; on Android, speed improvements are landing as well, and both
Android and iOS have a new look and feel. To learn more about Firefox
Quantum, visit the Mozilla Blog.

Security updates for Tuesday

Post Syndicated from ris original https://lwn.net/Articles/738995/rss

Security updates have been issued by Arch Linux (konversation), Debian (graphicsmagick and konversation), Fedora (git-annex, ImageMagick, kernel, and libgcrypt), Oracle (kernel), Red Hat (httpd), SUSE (firefox, nss), and Ubuntu (perl and postgresql-9.3, postgresql-9.5, postgresql-9.6).