BazelCon 2019

Cross-posted from the original BazelCon 2019 recap .

Last month the Google Bazel team hosted its largest ever Bazel user conference: BazelCon 2019, an annual gathering of the community surrounding the Bazel build system. This is the main Bazel event of the year which serves as an opportunity for Bazel contributors, maintainers, and users to meet and learn from each other, present Bazel migration stories, educate new users, and collaborate together on the future of Bazel.

BazelCon 2019 by the Numbers

• 400+ attendees (2x increase over BazelCon 2018)
• 125 organizations represented including Microsoft, Spotify, Uber, Apple, Cruise, EA, Lyft, Tesla, SpaceX, SAP, Bloomberg, Wix, Etsy, BMW and others
• 26 full-length talks and 15 lightning talks by members of the external community and Googlers
• 16 hours of Q&A during Office Hours with Bazel team members
• 45 Bazel Bootcamp attendees
• 5 Birds of a Feather sessions on iOS, Python, Java, C++ and Front-end Bazel rules
• 182 users in the #bazelcon2019 Slack channel

BazelCon 2019 Full Length Talks

The full playlist also includes lighting talks.

• Keynote: The Role of Catastrophic Failure in Software Design – Jeff Atwood (Stack Overflow/Discourse)
• Bazel State of the Union – John Field and Dmirty Lomov (Google)
• Building Self Driving Cars with Bazel – Axel Uhlig and Patrick Ziegler (BMW Group)
• Moving to a Bazel-based CI system: 6 Learnings – Or Shachar (Wix)
• Bazel Federation – Florian Weikert (Google)
• Lessons from our First 100,000 Bazel Builds – Kevin Gessner (Etsy)
• Migrating Lyft-iOS to Bazel – Keith Smiley and Dave Lee (Lyft)
• Test Selection – Benjamin Peterson (Dropbox)
• Porting iOS Apps to Bazel – Oscar Bonilla (LinkedIn)
• Boosting Dev Box Performance with Remote Execution for Non-Hermetic Build Engines – Erik Mavrinac (Microsoft)
• Building on Key - Keeping your Actions and Remote Executions in Tune – George Gensure (UberATG)
• Bazel remote execution API vs Goma – Mostyn Bramley-Moore (Vewd Software)
• Integrating with ease: leveraging BuildStream interaction with Bazel build for consistent results – Daniel Silverstone (Codethink)
• Building Self-Driving Cars with Bazel – Michael Broll and Nico Valigi (Cruise)
• Make local development (with Bazel) great again! – Ittai Zeidman (Wix)
• Gradle to Bazel – Chip Dickson and Charles Walker (SUM Global Technology)
• Bazel Bootcamp – Kyle Cordes (Oasis Digital)
• Bazel migration patterns: how to prove business value with a small investment – Alex Eagle and Greg Magolan (Google)
• Dynamic scheduling: Fastest clean and incremental builds – Julio Merino (Google)
• Building a great CI with Bazel – Philipp Wollermann (Google)

By Misha Narinsky, Bazel Team

Google Summer of Code 2020 is now open for mentor organization applications!

We are looking for open source projects and organizations to participate in the 16th annual Google Summer of Code (GSoC)! GSoC is a global program that draws university student developers from around the world to contribute to open source projects. Each student will spend three months working on a coding project with the support of volunteer mentors from participating open source organizations, mid-May to mid-August.

Last year, 1,276 students worked with 206 open source organizations and over 2,000 mentors. Organizations include small and medium sized open source projects, as well as a number of umbrella organizations with many sub-projects under them (Apache Software Foundation, Python Software Foundation, etc.).

Our 2020 goal is to accept more organizations into their first GSoC than ever before! We ask that veteran organizations refer other organizations they think would be a good fit to participate in GSoC.

You can apply to be a mentoring organization for GSoC starting today. The deadline to apply is February 5 at 19:00 UTC. Organizations chosen for GSoC 2020 will be publicly announced on February 20.

Please visit the program site for more information on how to apply and review the detailed timeline of important deadlines. We also encourage you to check out the Mentor Guide and our short video on why open source projects apply to be a part of the program.

Best of luck to all of the open source mentoring organization applicants!

By Stephanie Taylor, Google Open Source

Securing open source: How Google supports the new Kubernetes bug bounty

At Google, we care deeply about the security of open-source projects, as they’re such a critical part of our infrastructure—and indeed everyone’s. Today, the Cloud-Native Computing Foundation (CNCF) announced a new bug bounty program for Kubernetes that we helped create and get up and running. Here’s a brief overview of the program, other ways we help secure open-source projects and information on how you can get involved.

Launching the Kubernetes bug bounty program

Kubernetes is a CNCF project. As part of its graduation criteria, the CNCF recently funded the project’s first security audit, to review its core areas and identify potential issues. The audit identified and addressed several previously unknown security issues. Thankfully, Kubernetes already had a Product Security Committee, including engineers from the Google Kubernetes Engine (GKE) security team, who respond to and patch any newly discovered bugs. But the job of securing an open-source project is never done. To increase awareness of Kubernetes’ security model, attract new security researchers, and reward ongoing efforts in the community, the Kubernetes Product Security Committee began discussions in 2018 about launching an official bug bounty program.

Find Kubernetes bugs, get paid

What kind of bugs does the bounty program recognize? Most of the content you’d think of as ‘core’ Kubernetes, included at https://github.com/kubernetes, is in scope. We’re interested in common kinds of security issues like remote code execution, privilege escalation, and bugs in authentication or authorization. Because Kubernetes is a community project, we’re also interested in the Kubernetes supply chain, including build and release processes that might allow a malicious individual to gain unauthorized access to commits, or otherwise affect build artifacts. This is a bit different from your standard bug bounty as there isn’t a ‘live’ environment for you to test—Kubernetes can be configured in many different ways, and we’re looking for bugs that affect any of those (except when existing configuration options could mitigate the bug). Thanks to the CNCF’s ongoing support and funding of this new program, depending on the bug, you can be rewarded with a bounty anywhere from $100 to $10,000.

The bug bounty program has been in a private release for several months, with invited researchers submitting bugs and to help us test the triage process. And today, the new Kubernetes bug bounty program is live! We’re excited to see what kind of bugs you discover, and are ready to respond to new reports. You can learn more about the program and how to get involved here.

Dedicated to Kubernetes security

Google has been involved in this new Kubernetes bug bounty from the get-go: proposing the program, completing vendor evaluations, defining the initial scope, testing the process, and onboarding HackerOne to implement the bug bounty solution. Though this is a big effort, it’s part of our ongoing commitment to securing Kubernetes. Google continues to be involved in every part of Kubernetes security, including responding to vulnerabilities as part of the Kubernetes Product Security Committee, chairing the sig-auth Kubernetes special interest group, and leading the aforementioned Kubernetes security audit. We realize that security is a critical part of any user’s decision to use an open-source tool, so we dedicate resources to help ensure we’re providing the best possible security for Kubernetes and GKE.

Although the Kubernetes bug bounty program is new, it isn’t a novel strategy for Google. We have enjoyed a close relationship with the security research community for many years and, in 2010, Google established our own Vulnerability Rewards Program (VRP). The VRP provides rewards for vulnerabilities reported in GKE and virtually all other Google Cloud services. (If you find a bug in GKE that isn’t specific to Kubernetes core, you should still report it to the Google VRP!) Nor is Kubernetes the only open-source project with a bug bounty program. In fact, we recently expanded our Patch Rewards program to provide financial rewards both upfront and after-the-fact for security improvements to open-source projects.

Help keep the world’s infrastructure safe. Report a bug to the Kubernetes bug bounty, or a GKE bug to the Google VRP.

By Maya Kaczorowski, Product Manager, Container Security; and Aaron Small, Product Manager, GKE On-Prem security