opensource.google.com

Menu

Posts from August 2018

Introducing the Tink cryptographic software library

Thursday, August 30, 2018

Cross-posted on the Google Security Blog

At Google, many product teams use cryptographic techniques to protect user data. In cryptography, subtle mistakes can have serious consequences, and understanding how to implement cryptography correctly requires digesting decades' worth of academic literature. Needless to say, many developers don’t have time for that.

To help our developers ship secure cryptographic code we’ve developed Tink—a multi-language, cross-platform cryptographic library. We believe in open source and want Tink to become a community project—thus Tink has been available on GitHub since the early days of the project, and it has already attracted several external contributors. At Google, Tink is already being used to secure data of many products such as AdMob, Google Pay, Google Assistant, Firebase, the Android Search App, etc. After nearly two years of development, today we’re excited to announce Tink 1.2.0, the first version that supports cloud, Android, iOS, and more!

Tink aims to provide cryptographic APIs that are secure, easy to use correctly, and hard(er) to misuse. Tink is built on top of existing libraries such as BoringSSL and Java Cryptography Architecture, but includes countermeasures to many weaknesses in these libraries, which were discovered by Project Wycheproof, another project from our team.

With Tink, many common cryptographic operations such as data encryption, digital signatures, etc. can be done with only a few lines of code. Here is an example of encrypting and decrypting with our AEAD interface in Java:
 import com.google.crypto.tink.Aead;
    import com.google.crypto.tink.KeysetHandle;
    import com.google.crypto.tink.aead.AeadFactory;
    import com.google.crypto.tink.aead.AeadKeyTemplates;
     // 1. Generate the key material.
    KeysetHandle keysetHandle = KeysetHandle.generateNew(
        AeadKeyTemplates.AES256_EAX);
     // 2. Get the primitive.
    Aead aead = AeadFactory.getPrimitive(keysetHandle);
     // 3. Use the primitive.
    byte[] plaintext = ...;
    byte[] additionalData = ...;
    byte[] ciphertext = aead.encrypt(plaintext, additionalData);
Tink aims to eliminate as many potential misuses as possible. For example, if the underlying encryption mode requires nonces and nonce reuse makes it insecure, then Tink does not allow the user to pass nonces. Interfaces have security guarantees that must be satisfied by each primitive implementing the interface. This may exclude some encryption modes. Rather than adding them to existing interfaces and weakening the guarantees of the interface, it is possible to add new interfaces and describe the security guarantees appropriately.

We’re cryptographers and security engineers working to improve Google’s product security, so we built Tink to make our job easier. Tink shows the claimed security properties (e.g., safe against chosen-ciphertext attacks) right in the interfaces, allowing security auditors and automated tools to quickly discover usages where the security guarantees don’t match the security requirements. Tink also isolates APIs for potentially dangerous operations (e.g., loading cleartext keys from disk), which allows discovering, restricting, monitoring and logging their usage.

Tink provides support for key management, including key rotation and phasing out deprecated ciphers. For example, if a cryptographic primitive is found to be broken, you can switch to a different primitive by rotating keys, without changing or recompiling code.

Tink is also extensible by design: it is easy to add a custom cryptographic scheme or an in-house key management system so that it works seamlessly with other parts of Tink. No part of Tink is hard to replace or remove. All components are composable, and can be selected and assembled in various combinations. For example, if you need only digital signatures, you can exclude symmetric key encryption components to minimize code size in your application.

To get started, please check out our HOW-TO for Java, C++ and Obj-C. If you'd like to talk to the developers or get notified about project updates, you may want to subscribe to our mailing list. To join, simply send an empty email to tink-users+subscribe@googlegroups.com. You can also post your questions to StackOverflow, just remember to tag them with tink.

We’re excited to share this with the community, and welcome your feedback!

By Thai Duong, Information Security Engineer, on behalf of Tink team

Announcing Google Code-in 2018: nine is just fine!

Wednesday, August 29, 2018

We are excited to announce the 9th consecutive year of the Google Code-in (GCI) contest! Students ages 13 through 17 from around the world can learn about open source development by working on real open source projects, with mentorship from active developers. GCI begins on Tuesday, October 23, 2018 and runs for seven weeks, ending Wednesday, December 12, 2018.

Google Code-in is unique because, not only do the students choose what they want to work on from the 2,500+ tasks created by open source organizations, but they have mentors available to help answer their questions as they work on each of their tasks.

Getting started in open source software can be a daunting task for a developer of any age. What organization should I work with? How do I get started? Does the organization want my help? Am I too inexperienced?

The beauty of GCI is that participating open source organizations realize teens are often first time contributors, so the volunteer mentors come prepared with the patience and the experience to help these newcomers become part of the open source community.

Open source communities thrive when there is a steady flow of new contributors who bring new perspectives, ideas and enthusiasm. Over the last 8 years, GCI open source organizations have helped 8,108 students from 107 countries make meaningful contributions. Many of these students are still participating in open source communities years later. Dozens have gone on to become Google Summer of Code (GSoC) students and even mentor other students.

The tasks that contest participants will complete vary in skill set and level, including beginner tasks any student can take on, such as “setup your development environment.” With tasks in five different categories, there’s something to fit almost any student’s skills:
  • Code: writing or refactoring
  • Documentation/Training: creating/editing documents and helping others learn more
  • Outreach/Research: community management, marketing, or studying problems and recommending solutions
  • Quality Assurance: testing and ensuring code is of high quality
  • Design: graphic design or user interface design
Open source organizations can apply to participate as mentoring organizations for in Google Code-in starting on Thursday, September 6, 2018. Google Code-in starts for students October 23rd!

Visit the contest site g.co/gci to learn more about the contest and find flyers, slide decks, timelines, and more.

By Stephanie Taylor, Google Open Source

That’s a wrap for Google Summer of Code 2018

Wednesday, August 22, 2018

We are pleased to announce that 1,072 students from 59 countries have successfully completed the 2018 Google Summer of Code (GSoC). Congratulations to all of our students and mentors who made this our biggest and best Google Summer of Code yet.

Over the past 12 weeks, GSoC students have worked diligently with 212 open source organizations and over 2,100 mentors from all around the world, learning to work with distributed teams and developing complex pieces of code. Student projects are now public – take a closer look at their work.

Open source communities need new ideas to keep projects thriving and evolving; GSoC students bring fresh perspectives while helping organizations enhance, extend, and refine their codebases. This is not the end of the road for GSoC students! Many will go on to become mentors in future years and many more will become long-term committers.

And finally, a big thank you to the mentors and organization administrators who make GSoC possible. Their dedication to welcoming new student contributors into their communities is awesome and inspiring. Thank you all!

By Mary Radomile, Google Open Source

ZuriHac 2018: Haskell hackathon in Rapperswil

Friday, August 17, 2018

Google Open Source recently co-sponsored a three-day hackathon for Haskell, an open source functional programming language. Ivan Krišto from Google’s Zürich office talks more about the event below.

Over the weekend of June 9th, Rapperswil, Switzerland became a home for 300 Haskellers. Hochschule für Technik Rapperswil hosted the seventh annual ZuriHac, the biggest Haskell Hackathon in Europe. ZuriHac is a free, international coding festival with the goal to expand our community and to build and improve Haskell libraries, tools and infrastructure.

Participants could choose to hack all day long, attend the Haskell beginners course led by Julie Moronuki, join the Glasgow Haskell Compiler (GHC) DevOps track organized by GHC contributors with the goal to bring in new contributors, listen to the Haskell flavoured talks, or socialize and swim in the lake. The event was colocated with C++ standardization committee meetings which offered a unique opportunity for sharing ideas between the two communities.

Here is a short summary of featured talks at ZuriHac.
The event concluded with a presentation of the results of the three day hackathon: project presentations.

Video by Hochschule für Technik Rapperswil.

Once again, we broke the attendance record! We’re already preparing for ZuriHac 2019 and hope to keep up this amazing growth. See you next year!

By Ivan Krišto, Software Engineer

Congratulations to the latest Google Open Source Peer Bonus winners

Wednesday, August 15, 2018

We are pleased to announce the latest round of Google Open Source Peer Bonus winners and the projects they support.

Open source software is a cornerstone of software development inside and outside of Google, and the Google Open Source Peer Bonus program is one way we thank the people who make our work possible. Twice a year we invite Googlers to nominate external contributors to be rewarded for their contribution to open source projects.

This time we have a truly international team of recipients from Australia, Brazil, Canada, Germany, India, Italy, Ireland, France, Japan, Netherlands, Russia, Singapore, Switzerland, Sweden, UK and USA. You can learn about previous recipients in these blog posts.

Projects range from Linux distributions and version control systems to monitoring and testing software. Some are part of the backbone of our industry, others are critical dependencies of specific products and services we offer. All of them are important to us!

Listed below are the individuals who gave us permission to thank them publicly:

Name Project Name Project
Sultan AlsawafAndroid KernelRavi Santosh GudimetlaKubernetes
Allan McRaeArch LinuxSteve KuznetsovKubernetes
Seth Pollackaws-encryption-providerHisham MuhammadLuaRocks
George GensureBazel BuildfarmYutaka Matsubarameinheld
Omar CornutDear ImGuiPulkit GoyalMercurial
Alessandro ArzilliDelveYuya NishiharaMercurial
Matt KleinEnvoyAdam Mummery-SmithMixin
Ivan GrokhotkovESP8266 core for ArduinoArnout EngelenNotion
Esther OnfroyExodus PrivacyBrian BrazilPrometheus
Yao LiForkliftBruno Oliveirapytest
Warner LoshFreeBSDJames FriedmanRMWC
Elijah NewrenGitSteve KlabnikRust Book
Gábor SzederGitJack LukicSemantic UI
Alvaro Viebrantzgoogle-cloud-iot-arduinoVidar HolenShellCheck
Richard MusiolGopherJS, go-wasmIvan PopelyshevSkia graphics in Chrome
Tobias FuruholmGrafeasSpencer GibbSpring Cloud
David PursehouseJGitDaniel AlmSwift gRPC
Brian GrangerJupyterYong TangTensorFlow
Rodrigo MenezeskopsJason ZamanTensorFlow, Gentoo, SELinux
Rohith JayawardenekopsKai SasakiTensorFlow.js
Kam KasraviKubeflowManraj GroverTensorFlow.js
Pete MacKinnonKubeflowStefan WeilTesseract
Christoph BleckerKubernetesSumana HarihareswaraWarehouse (PyPI)
Davanum SrinivasKubernetesJia Lizone.js

Once again we would like to express our gratitude and appreciation to current and former recipients for their hard work, time and devotion to open source. Without you these projects wouldn’t thrive!

We look forward to your ongoing contributions and can’t wait to recognize even more contributors for their work in 2019.

By Maria Tabak, Google Open Source

How we brought the latest version of Python to App Engine and Cloud Functions

Monday, August 13, 2018

At Cloud Next 2018, we added Python 3.7 support to Cloud Functions and now we’ve announced Python 3.7 support for the App Engine standard environment. These new runtimes allow you to write Python functions and apps using the latest version of Python and the rich ecosystem of packages available on Python Packaging Index (PyPI).

This new runtime marks a significant update to App Engine and was enabled by new open source software that we recently released: gVisor and FTL.

Python, straight from the source

Running Python 3.7 on App Engine and Cloud Functions required us to fundamentally rethink our infrastructure. Traditionally, meeting Google Cloud’s security requirements meant that we had to run a modified version of the Python interpreter. However, using a modified interpreter constrained some language features and only allowed us to support a limited set of whitelisted Python libraries.

Thanks to gVisor, a container sandbox that provides improved security and process isolation, we can now run the unmodified Python 3.7.0 interpreter. We’ve done extensive testing to make sure Python 3.7 is compatible with gVisor. As part of our compatibility testing, we run Python’s full suite of language tests, and tests for Python packages that are popular on PyPI. We’re committed to ensuring that everything you’ve come to know and love about Python is supported on our platform.

Seamless deployments

Most importantly, this change in our infrastructure makes it easier to take advantage of Python’s vast ecosystem. As a developer, you just add project dependencies to a requirements.txt file and deploy.

During deployment, FTL, a tool for building containers, fetches dependencies listed in your requirements.txt file and installs them alongside your app or function. FTL also includes a short-lived dependency cache, which speeds up repeated deployments if no changes are detected in your requirements.txt file. This is particularly useful if you find just need to re-deploy because you found a typo.

Keeping up with the Pythonistas

In making these changes, we also decided to expand the list of system packages that are included with each runtime’s Ubuntu 18.04 distribution. We think that will make life just a little bit easier for developers working with the latest release of Python.

Looking forward, we’re excited about how these changes will allow us to keep up with the Python community’s progress as they release new versions and libraries. Please let us know what you think and if you run into any challenges.

You can learn more about how to get started with it on App Engine and Cloud Functions in our documentation. We can’t wait to see what you build with Python 3.7.

By Stewart Reichling, Product Manager

OpenMetrics project accepted into CNCF Sandbox

Friday, August 10, 2018

For the past several months, engineers from Google Cloud, Prometheus, and other vendors have been aligning on OpenMetrics, a specification for metrics exposition. Today, the project was formally announced and accepted into the CNCF Sandbox, and we’re currently working on ways to support OpenMetrics in OpenCensus, a set of uniform tracing and stats libraries that work with multiple vendors’ services. This multi-vendor approach works to put architectural choices in the hands of developers.
+
OpenMetrics stems from the stats formats used inside of Prometheus and Google’s Monarch time-series infrastructure, which underpins both Stackdriver and internal monitoring applications. As such, it is designed to be immediately familiar to developers and capable of operating at extreme scale. With additional contributions and review from AppOptics, Cortex, Datadog, InfluxData, Sysdig, and Uber, OpenMetrics has begun the cross-industry collaboration necessary to drive adoption of a new specification.

OpenCensus provides automatic instrumentation, APIs, and exporters for stats and distributed traces across C++, Java, Go, Node.js, Python, PHP, Ruby, and .Net. Each OpenCensus library allows developers to automatically capture distributed traces and key RPC-related statistics from their applications, add custom data, and export telemetry to their back-end of choice. Google has been a key collaborator in defining the OpenMetrics specification, and we’re now focusing on how to best implement this inside of OpenCensus.

“Google has a history of innovation in the metric monitoring space, from its early success with Borgmon, which has been continued in Monarch and Stackdriver. OpenMetrics embodies our understanding of what users need for simple, reliable and scalable monitoring, and shows our commitment to offering standards-based solutions,” said Sumeer Bhola, Lead Engineer on Monarch and Stackdriver at Google.

For more information about OpenMetrics, please visit openmetrics.io. For more information about OpenCensus and how you can quickly enable trace and metrics collection from your application, please visit opencensus.io.

By Morgan McLean, Product Manager for OpenCensus and Stackdriver APM

Introducing the new lead for Android Open Source Project

Wednesday, August 8, 2018

This week began with the announcement of Android 9 Pie and, as usual, the subsequent upstreaming of code to the Android Open Source Project (AOSP). But the release of Android 9 isn’t the only important Android news!

Tucked away in the announcement to the Android Building mailing list was this note:

“I also wanted to take a moment to introduce myself as the new Tech Lead / Manager for AOSP. My name is Jeff Bailey, and I’ve been involved in the Open Source community for more than two decades. Since I joined the Android team a few months ago, I’ve been learning how we do things and getting an understanding of how we could work better with the community. I’d love to hear from you: @JeffBaileyAOSP on Twitter or jeffbailey+aosp@google.com. Be well!”

As Jeff notes in his introduction, he has a history in free and open source software (FOSS). He’s been an avid user, contributor, and maintainer since before the Open Source Definition was inked!

Jeff co-founded Savannah, where GNU software is developed and distributed, spent 15 years working on Debian, and has been an Ubuntu core developer. Further, he spent some time on the Google Open Source team and was involved in open sourcing Android back in 2008.

Open source projects, even those which originate inside of companies, are powered by the community of users and contributors that surround them. And those communities thrive when they have stewards who are steeped in the traditions of free and open source software. We’re excited for AOSP as Jeff takes the reins. He brings both technical and cultural skills to the table, and he’s been involved with the project since the beginning!

Suffice it to say, AOSP is in good hands. We welcome Jeff to his new role and, as he said in his introduction, he’d love to hear from the community: you can reach Jeff on Twitter and via email.

By Josh Simmons, Google Open Source

Magnificent mentors of Google Summer of Code 2018

Thursday, August 2, 2018

Mentors are the heart and soul of the Google Summer of Code (GSoC) program and have been for the last 14 years. Without their hard work and dedication, there would be no Google Summer of Code. These volunteers spend 4+ months guiding their students to create the best quality project possible while welcoming them into their communities – answering questions and providing help at all hours of the day, including weekends and holidays.

Thank you mentors and organization administrators! 

Each year we pore over heaps of data to extract some interesting statistics about the GSoC mentors. Here’s a quick synopsis of our 2018 crew:
  • Registered mentors: 2,819
  • Mentors with assigned student projects: 1,996
  • Mentors who have participated in GSoC for 10 or more years: 46
  • Mentors who have been a part of GSoC for 5 years or more: 272
  • Mentors that are former GSoC students: 627
  • Mentors that have also been involved in the Google Code-in program: 474
  • Percentage of new mentors: 36.5%
GSoC 2018 mentors are from all parts of the world, hailing from 75 countries!

If you want to see the stats for all 75 countries check out this list.


Another fun fact about our 2018 mentors: they range in age from 15-80 years old!
  • Average mentor age: 34
  • Median mentor age: 33
  • Mentors under 18 years old: 26*
GSoC mentors help introduce the next generation to the world of open source software development – for that we are very grateful. To show our appreciation, we invite two mentors from each of the 206 participating organizations to attend our annual mentor summit at the Google campus in Sunnyvale, California. It’s three days of community building, lively debate, learning best practices from one another, working to strengthen open source communities, good food, and lots and lots of chocolate.

Thank you to all of our mentors, organization administrators, and all of the “unofficial” mentors that help in the various open source organization’s communities. Google Summer of Code is a community effort and we appreciate each and every one of you.

Cheers to yet another great year!

By Stephanie Taylor, Google Open Source

* Most of these 26 young GSoC mentors started their journey in Google Code-in, our contest for 13-17 year olds that introduces young students to open source software development.

Announcing Cirq: an open source framework for NISQ algorithms

Wednesday, August 1, 2018

Cross-posted from the Google AI Blog

Over the past few years, quantum computing has experienced a growth not only in the construction of quantum hardware, but also in the development of quantum algorithms. With the availability of Noisy Intermediate Scale Quantum (NISQ) computers (devices with ~50 - 100 qubits and high fidelity quantum gates), the development of algorithms to understand the power of these machines is of increasing importance. However, a common problem when designing a quantum algorithm on a NISQ processor is how to take full advantage of these limited quantum devices—using resources to solve the hardest part of the problem rather than on overheads from poor mappings between the algorithm and hardware. Furthermore some quantum processors have complex geometric constraints and other nuances, and ignoring these will either result in faulty quantum computation, or a computation that is modified and sub-optimal.*

Today at the First International Workshop on Quantum Software and Quantum Machine Learning (QSML), the Google AI Quantum team announced the public alpha of Cirq, an open source framework for NISQ computers. Cirq is focused on near-term questions and helping researchers understand whether NISQ quantum computers are capable of solving computational problems of practical importance. Cirq is licensed under Apache 2, and is free to be modified or embedded in any commercial or open source package.

Once installed, Cirq enables researchers to write quantum algorithms for specific quantum processors. Cirq gives users fine tuned control over quantum circuits, specifying gate behavior using native gates, placing these gates appropriately on the device, and scheduling the timing of these gates within the constraints of the quantum hardware. Data structures are optimized for writing and compiling these quantum circuits to allow users to get the most out of NISQ architectures. Cirq supports running these algorithms locally on a simulator, and is designed to easily integrate with future quantum hardware or larger simulators via the cloud.


We are also announcing the release of OpenFermion-Cirq, an example of a Cirq based application enabling near-term algorithms. OpenFermion is a platform for developing quantum algorithms for chemistry problems, and OpenFermion-Cirq is an open source library which compiles quantum simulation algorithms to Cirq. The new library uses the latest advances in building low depth quantum algorithms for quantum chemistry problems to enable users to go from the details of a chemical problem to highly optimized quantum circuits customized to run on particular hardware. For example, this library can be used to easily build quantum variational algorithms for simulating properties of molecules and complex materials.

Quantum computing will require strong cross-industry and academic collaborations if it is going to realize its full potential. In building Cirq, we worked with early testers to gain feedback and insight into algorithm design for NISQ computers. Below are some examples of Cirq work resulting from these early adopters:
To learn more about how Cirq is helping enable NISQ algorithms, please visit the links above where many of the adopters have provided example source code for their implementations.

Today, the Google AI Quantum team is using Cirq to create circuits that run on Google’s Bristlecone processor. In the future, we plan to make this processor available in the cloud, and Cirq will be the interface in which users write programs for this processor. In the meantime, we hope Cirq will improve the productivity of NISQ algorithm developers and researchers everywhere. Please check out the GitHub repositories for Cirq and OpenFermion-Cirq — pull requests welcome!

By Alan Ho, Product Lead and Dave Bacon, Software Lead, Google AI Quantum Team

Acknowledgements
We would like to thank Craig Gidney for leading the development of Cirq, Ryan Babbush and Kevin Sung for building OpenFermion-Cirq and a whole host of code contributors to both frameworks.



* An analogous situation is how early classical programmers needed to run complex programs in very small memory spaces by paying careful attention to the lowest level details of the hardware.
.