Uptane isn't just for automotive applications anymore. For a number of years now, we've seen adoption of Uptane in other sectors that have high security requirements, like robotics, civil infrastructure, and industrial automation. In the embedded Linux space, for example, Torizon Cloud has been providing Uptane-as-a-service for IoT and industrial automation for years. Any domain where you want security, software/firmware updates to multiple independent compute units or components, reliable and secure software manifests, or secure offline updates is a good domain to implement Uptane in.

But I'm writing today about a major new piece of legislation from the European Union: the Cyber Resilience Act (CRA). It was adopted without changes last week by the Council of the EU, meaning it will enter into force very shortly--the remaining steps are merely procedural, such as publishing official translations in the EU's legislative journal. The CRA's requirements talk a lot about software updates, though, and it looks like Uptane is a perfect way to meet those requirements.

What is the Cyber Resilience Act? Why now?​

The Cyber Resilience Act is no joke: it imposes serious new cybersecurity requirements on any product with digital elements offered for sale anywhere in the European Union, and serious fines for any manufacturer (or importer) selling that don't comply. The EU looked at the landscape of cybersecurity in IoT, consumer electronics, industrial control systems, and more, and found it to be seriously lacking. Devices get shipped with ancient firmwares rife with security holes, and never get patched. Those devices end up getting compromised by cyber-criminals, and causing trouble not just for the people who bought them, but for the whole world: botnets of millions of compromised IoT devices are one of the biggest vectors for DDOS attacks, for example.

But market forces don't do a great job of incentivizing good cybersecurity practices, unfortunately. The average consumer has no way to tell the difference between IoT products with good cybersecurity practices and bad ones, and it's a lot cheaper to claim to be secure than to actually put in the work to be secure.

So what can be done when market forces are failing, and profit motives are causing negative externalities? Regulation, with steep penalties for bad actors. Selling products that turn into botnets because it's cheaper not to patch actively exploited security holes isn't all that different from dumping dangerous chemicals into a stream because it's cheaper than disposing of them properly. With the CRA's penalties of up to 2.5% of global annual revenue (or 15 million euros, whichever is higher), the profitability equation drastically changes.

The CRA has three main pillars. The first pillar is product-related essential requirements, the second is mandating continuing responsibility for handling security issues and vulnerabilities after the product is sold, and the third relates to properly informing end users about support periods and other important cybersecurity features. I'm going to look only at the first two pillars here.

A surprising portion of the new concrete requirements under the CRA relate to software updates. That shouldn't be a surprise to most cybersecurity professionals: exploits happen, and when they do, they need to be patched. The fact that so many connected devices ship without a software update system, or with an insecure or incomplete software update system, is the root cause of a lot of problems. For those reasons, some of the CRA's most detailed and specific requirements relate to software updates.

Uptane and the CRA: A natural fit​

So, we have a major new regulation that mandates broad adoption of over-the-air software update systems. Uptane was developed to be a secure over-the-air software update system against an incredibly strong threat model; one of the talks that Prof. Cappos would often give in the early years of Uptane was entitled Securing Over-the-Air Updates Against Nation State Actors. So it's not surprising that Uptane is a natural choice for meeting CRA obligations.

Software update client requirements​

Let's look at some of those concrete requirements. First off, software updates are absolutely mandatory:

Products shall:

• ensure that vulnerabilities can be addressed […] through automatic security updates that are enabled as a default setting

This requirement clearly indicates the need for an active update system. It is not sufficient, for example, to publish a software update and notify the user that it's available. The product itself needs to be able to automatically check for and install security updates. But of course, automatic updates are themselves potentially a serious attack vector. But the CRA's framers understand the same thing that the automotive industry does: automatic updates are themselves an extremely dangerous attack vector. So it also prescribes that these updates need to be distributed securely:

Products shall:

• provide for mechanisms to securely distribute updates […] in an automatic manner

Here, and throughout the regulation, the CRA doesn't delve into specifics. EU-level regulation tends to be written in common-sense, plain language; the details of what it means for an mechanism of distributing updates to be secure is left up to the experts. But clearly, applying a known and established standard like Uptane is one of the best ways to ensure compliance. Software update security isn't an easy problem, and many high-profile, real-world software update systems have had major compromises over the years. Rolling your own update system is usually a bad idea.

Vulnerability monitoring and per-device requirements​

The CRA mandates a support period for every product of at least 5 years. During the support period, you are responsible for reviewing the security of the software on the product, and ensuring that any exploitable vulnerability of the product is patched without delay:

Manufacturers of products with digital elements shall:

• in relation to the risks posed to products with digital elements, address and remediate vulnerabilities without delay, including by providing security updates
• apply effective and regular tests and reviews of the security of the product with digital elements

Obviously having a reliable, flexible, and secure software update system is a prerequisite for meeting these requirements. But there's another issue: under the CRA, you might have different support obligations for different products, even of the same SKU.

That's because the support period is defined by, and starts when, the product is placed on the market. If you follow that link, you'll see the detailed legal definition of what it means to be "placed on the market" in the European Union, but the crux of it is that (1) "placing on the market" is a concept that applies to individualized products, not SKUs or product lines, and (2) a product cannot be considered to be placed on the market before it is actually manufactured. That means that you may have different support obligations for different individual products of the same SKU:

One solution to this issue is simply to extend support to all products of a particular SKU until 5 years after the last one is manufactured. But if that's not feasible or desirable, you need a way to accurately determine when your support obligations for each product expire. Uptane's signed software manifests provide this: every time a device checks for an update, it sends a manifest. In that manifest, there is a report generated and cryptographically signed by each component of the device detailing exactly what software/firmware it has installed, identified by the software/firmware's hash.

This is perfect for tracking support obligations! Even though your product tracking needs might not be as detailed as an automaker's, leveraging Uptane's built-in reporting mechanism can still help you do compliance tracking. The fact that the reports also tell you exactly what software the devices in the field are running is just an added bonus. The software manifests also let you can keep track of how many devices successfully upgrade when run an update campaign, and will also alert you if malicious software is installed or software is unexpectedly downgraded.

Final thoughts​

The Cyber Resilience Act is here, and it brings meaningful new requirements. Uptane can help you meet quite a lot of them, because many of the things the CRA requires were already core requirements for Uptane back when we started designing it in 2015. I'm personally very happy to see these principles make it into law and regulations, because I firmly believe that keeping devices up to date with regular software updates is one of the most effective ways to increase cybersecurity for everyone. But at the same time, automatic software update systems are extremely dangerous if they aren't implemented properly. So I very much encourage any device manufacturer that finds itself suddenly in need of an automatic update system to look first at an Uptane-based one. You can implement Uptane yourself, or you can use existing implementations. There are free-as-in-beer, free-as-in-speech, and SaaS offerings available. I already gave a run-down of the various options in my last blog post, so I won't repeat myself here. (Full disclosure: I am paid to work on Torizon Cloud, an Uptane-based SaaS offering.)

To offer a slight spin on an old proverb: the best time to integrate an Uptane software update system was at the beginning of your product design process. The second best time is today.

When: June 7, 2024, 10 a.m. to 3:30 p.m.
Format: Online via Zoom and in-person
Location: Renesas Electronics America, Inc
34705 W 12 Mile Rd #300, Farmington Hills, MI 48331
Registration: Uptane Workshop Registration

Just a day after the escar USA automotive security conference, the Uptane Community invites you to explore the critical role of secure software update technology in the automotive sector and beyond. This hybrid event will feature:

• Updates on the Uptane Standard and community initiatives
• Introduction of Google Summer of Code Uptane contributors and the 2024 projects
• Discussion: Harmonization with industry standards and regulations
• Adopter Talks: Insights into Uptane's real-world applications
• Expert Panel: Crypto agility and preparing for quantum-resistant technologies

Event Agenda​

Time (EDT)	Speaker	Topic
10:00	Jon Oster	Welcome and introduction
10:15	Philip Lapczynski	Uptane 101 and Uptane Updates
10:45		Break
11:00	Ira McDonald	OTA Standards Harmonization
11:15	Leo Cui	Google Summer of Code (GSoC) Projects Update
11:30	Jon Oster	Uptane Adoption
12:00		Lunch
13:00	Dr. Bob Kaster	Optimizing Secure Boot
13:30	Mark Johnson	Uptane++ and Uptane Certification
14:00		Break
14:15	Winnie Aideyan	Standardized Modular Secure Firmware Update Framework For Military Vehicles
14:45	(Moderator) Andre Weimerskirch (Panelists) Rita Barrios Bill Mazzara Phil Lapczynski	Crypto Agility Panel
15:25		Wrap Up

Let me get this out of the way right at the start: Uptane can be an intimidating project to take on. Why is that? Well, first of all, Uptane is a standard, not a specific piece of software. That in itself is always difficult because it's harder to engage with an abstract set of rules and concepts than with a real piece of software. But even beyond that, Uptane is different from other standards you might read. It doesn't specify an exact wireline formats and metadata schema that must be implemented. Furthermore, Uptane kind of sits "in the middle" on a software update architecture diagram.

In this post, I want to do three things. First, I'm going to answer the question, "Why should I want to use Uptane, and where?" Second, I'm going to give a really high-level overview of what Uptane is. I'm not going to get into specifics of how Uptane works, I just want to describe what it is, and what it does. And finally, I want to show the easiest way to start using a system that delivers software updates through Uptane by making use of open-source implementations of various parts of an Uptane system.

Why should I use Uptane?​

Uptane isn't just for vehicles!

Uptane was designed as a system to safely and securely deliver software updates to vehicles. That means it was designed to work under some difficult constraints. To begin with, there are dozens of different microcontrollers inside a vehicle, all running software that might need to be updated, and are connected by a number of different buses. There are challenging regulatory requirements, as well. A vehicle might only be road-legal with certain approved firmwares running on safety-critical parts. So you need to make sure that vehicles can report the software they're running in a verifiable way, and you need to be able to control the complete set of software and firmware running on the vehicle.

These factors make Uptane a really good choice for many other kinds of software updates to embedded devices. Medical devices, industrial automation, robotics, and other fields can also benefit from using an Uptane system. The rule of thumb you should use is this: if end users will be making choices about the firmware on the device that go beyond choosing if/when to install the latest updates, you probably want "basic" TUF. If the devices should be controlled more centrally, with the manufacturer (or some other entity) choosing when software updates should be delivered, you should use Uptane.

What is Uptane?​

Uptane is a standard, a set of rules to follow that will make your software update system resilient to a wide variety of real-world, long-term attacks. Uptane has various implementations, most of them proprietary, and many of them confidential and inside automotive companies. But to understand what it is, the best thing will be to show some diagrams.

This is a software repository, and a device that connects to it and installs an update. (I'm going to just say "device" for the purposes of this article. It might be a vehicle, or a robot, or an MRI machine.)

Let's say the repository is just an FTP server. It has some firmware images in it, in some kind of predictable directory structure. To make the repository more secure, you can follow the TUF standard. TUF describes how to add some signed metadata to a "normal" software repository like this, to make it possible for anyone who connects to the repository to verify a number of important properties related to timeliness, authenticity, and consistency. A TUF-compliant client can verify that:

• The owner of the repository decided which packages to let in
• The publisher of each package signed their own software and uploaded it
• The versions of the packages I see here are actually the latest ones, or at least they're out of date by no more than some known amount of time
• The hash of every binary/firmware image on the repository can be independently checked and verified, in an automated way
• None of the keys used for signing software have been revoked
• ...and a number of other things; the overall threat model that TUF protects against is too large for a bullet-point list

This is great, and is enough for securing traditional package repositories, where the end user knows what to install--think PyPI, npm, apt, or Cargo. It also allows the publisher to remove packages from the repo, and prevent them from being installed. For example, if a version was discovered to have a serious bug, you can simply remove it from the repository to prevent people from installing it. (Compare this to signing each release package with, say, a GPG key that users store in their keyring: if you want prevent naïve users/clients from installing a particular version, you have to also revoke the key used to sign it, and try to make sure that the revocation is propagated. Not an easy task, which is why it's so rarely done.) Let's look at our picture now:

But we need a bit more than this. Our clients are embedded devices or vehicles: we don't want to just give them a list of every possible package that exists and let them sort out what to install. We need to actually give them instructions about what to install, and we also need to know what's currently installed on them. This is where Uptane comes in. Uptane builds on TUF, adding a second entity called the Director repository. The Director repository is responsible for, well, directing the devices to install the software they're supposed to have installed, via whatever internal business logic is required. It also processes and validates the manifests that the devices send, so it's a reliable source of truth for what software is currently installed. Again, I'm not going to get into detail about how it does this; for now it's enough to know what it does.

So, once you have a Director repository, an Image repository, and a device, the picture is complete. In broad strokes, the protocol for checking for an update goes like this:

That's more or less it. Of course, there are many, many details. The bulk of the standard relates to the exact procedures for how the device checks the metadata and signatures. And of course, we've ignored the question of how software gets into a repository, how the signing keys are managed, and how Director decides what should be installed on the device. Uptane also deals with "secondaries," meaning that one internet-connected microcontroller or embedded Linux device can download and validate firmware updates for other microcontrollers; you can read elsewhere about how secondaries work.

What Uptane Isn't​

If you've gotten to this point, you've probably realized that there is a significant amount of stuff missing from the picture. Uptane doesn't say anything about:

• an interface to manage the software in the repository
• how to keep track of the information Director gets from the devices
• how Director decides what software the device should have installed
• how the device actually installs the update
• how the device authenticates itself to the repository
• transport security between the repository and the device (though Uptane is resilient to transport security compromise)

So there's a lot of other stuff that you need to attach Uptane concepts to before you have a complete update system. Some of those things might be relatively easy, some harder, but there are certainly a lot of them.

The reason Uptane was created this way is that it was written to solve real problems with existing systems. TUF was created as a way for existing software repositories to improve their security; those repositories already had systems for developers to register their package names and upload their software, and clients that know how to install the packages. Uptane was created to be used by automakers who already have software repositories, suppliers sending them firmware, quality control processes for what constitutes a software release, aftersales and maintenance departments keeping track of what parts might need software updates, and so on. It's a standard that answers the question, "How can I make my existing, complex system safer?" It would also make the standard very bloated and very inflexible if we made arbitrary decisions about those auxiliary pieces; we want the Uptane Standard to remain focused on solving supply-chain security and software deployment security.

But what if you are coming at it from the opposite direction? You don't already have a big complex system to secure, and you just want to set up a software repository and deliver software updates to embedded devices, using best practices from the start? In short, now that you know what Uptane is and what Uptane isn't, how can you actually use it?

Ways to use Uptane Today​

So, for a full Uptane system, you need:

• An Image repository, with some APIs/interfaces for doing common things
• A Director repository, with some way to create software updates and assign them to devices
• A client on your device that can talk to your server, and install updates

There are actually pretty easy options for all of these things, including both free-as-in-beer and free-as-in-speech resources.

Servers/repositories​

• OTA Community Edition

OTA Community Edition is the open-source, community-maintained Uptane implementation. It implements an Image repository, Director repository, and a device registry to keep track of the manifests (and other information) the devices send. It has HTTP REST APIs for all of the basic necessities for Uptane, but also for the practical bits that you need, like actually assigning updates to devices, uploading software, generating keys, and so on.

The OTA Community Edition repository contains instructions for how to spin up the services on a local network; to run an adequate production instance you'll need to fill in some blanks. It doesn't currently have a well-maintained web UI, but it's still possible to use the UI that was previously developed and open-sourced by HERE Technologies, once you make a few modifications to stub out API calls to their proprietary services. (P.S.: If you're interested in contributing to Uptane, developing a community-maintained web UI for OTA Community Edition is one of the projects we're proposing for Google Summer of Code 2024!)

• app.uptanedemo.org

I've spun up an instance of OTA Community Edition to help people get their feet wet, for free. It's open to the public as a demo instance, with all of its private signing keys published publicly (so, buyer beware: if you connect a device to this instance, anyone who wanted to could install malicious software). I wipe and reset it periodically. Some documentation on how to use it is coming soon, but for now, just pop into Discord and ask if you'd like to connect a device to it.

• Torizon Cloud

Torizon Cloud is a service provided by Toradex, built around Uptane. You can make a limited-usage account for free; if you go beyond 10 devices you have to pay. Disclosure: I work for Toradex on the team that develops Torizon Cloud, so this is self-promotion. The service is primarily geared at people running Toradex's embedded Linux distro Torizon OS, but it is a perfectly normal Uptane server that you can use with any of the client options below.

• Other commercial Uptane providers

There are other commercial providers of Uptane services, including Airbiquity's OTAMatic, HERE's OTA Connect, and CAROTA's Remote Updates. However, there don't appear to be open-source offerings of any of the parts, or demo servers that can be accessed without a commercial contract. (If anyone from those companies wants to reach out and correct me on that, I'm happy to add a link.)

Clients​

• Build your own using libaktualizr

The main way to get an Uptane client is to build one using libaktualizr. The aktualizr repository does include reference clients that can talk to OTA Community Edition servers. However, to really make use of Uptane and aktualizr, you'll want it to be integrated in your embedded Linux build.

• Add aktualizr to your existing embedded Linux using meta-updater

Most people building embedded Linuxes these days use Yocto. You can use meta-updater to integrate aktualizr into your Yocto build. There will be some work to do if you want to use it with an unsupported board; in particular you'll need to integrate OSTree and your bootloader, to deploy the images.

• Use Torizon OS or Common Torizon

This is probably the easiest way to get started. Torizon OS is a Linux distribution tailored for Toradex's embedded system-on-modules, so if you have Toradex hardware it's built right in. But even if you don't have a Toradex module, you can still use Common Torizon. It's a Toradex-sponsored and community-maintained port of Torizon OS to non-Toradex hardware; you can install it on a Raspberry Pi or even an x86 machine or VM.

Next steps​

Hopefully this has been a good primer for getting started with the Uptane project! We're planning to release more blog posts in the near future digging a little bit deeper into aktualizr and OTA Community Edition, but if you have questions or topics you're interested in seeing on the Uptane blog, let us know. You can always join our Discord.

Greetings, Uptane community! 👋

We are thrilled to announce that Uptane's sponsoring organization, the Linux Foundation, has officially become a part of the 2024 edition of Google Summer of Code (GSoC). This will mark Uptane's third year of mentoring GSoC projects under the Linux Foundation umbrella and we couldn't be more excited about the opportunities it presents. 🎉

At its core, GSoC represents more than just a mentoring program; it's a gateway to welcome and engage new contributors to the realm of open source software. It embodies the spirit of giving back, of investing a small portion of time to make a monumental difference, not only in the future endeavors of the GSoC contributors, but also for the broader Uptane community that will reap the benefits of these collaborations. 🌟

We extend a warm welcome to all new GSoC contributors considering becoming mentees within the Uptane community. We believe that this experience will not only enhance your technical skills, but also provide valuable insights into the workings of our community. Applying to work on one of our projects presents an opportunity to learn from individuals who are not only passionate about the Uptane ecosystem, but also deeply committed to making a positive impact on others' lives, be it GSoC contributors or those who utilize the project itself. 🤝

The Road to GSoC 2024: What’s Next? 🚀​

With GSoC now officially announced, we anticipate a surge in potential contributors reaching out about our projects through our Discord channel. In the coming weeks, our focus will be on assisting these participants in finding projects that align with their interests, exploring relevant domains, and refining their project proposals before the April 2nd deadline (UTC). Subsequently, we will meticulously review applications, select projects, and assemble mentor teams to facilitate the process. 🔍

For detailed information about available project ideas, please refer to our blog.

How Do I Apply? 📝

We urge interested participants to engage with the Uptane community early on. Try to join our weekly project meeting and/or bi-weekly Uptane Standard meetings, and become active members of our Discord server to stay informed about upcoming events and discussions. Doing this will help you get a better understanding of the projects and the Uptane community, which will be very beneficial while choosing projects and preparing your proposals.

Although the application period officially commences on March 18th (UTC), we advise candidates to commence preparations without delay. Utilize this time to refine project proposals, familiarize yourselves with Uptane, and delve deeper into your proposed areas of study. Detailed project descriptions are available here on The Linux Foundation's official wiki page, and our mentors are preparing resources to aid contributors in their initial exploration.

Important Dates for GSoC 2024 📅​

• February 22 - March 17: Potential GSoC contributors discuss application ideas with mentoring organizations.
• March 18: GSoC contributor application period begins.
• April 2: GSoC contributor application deadline.
• May 1: Accepted GSoC contributor projects announced.
• May 1 - 26: Community Bonding Period.
• May 27: Coding officially begins!
• July 8: Midterm evaluation.
• August 26 - September 2: Mentors submit final GSoC contributor evaluations (standard coding period).
• September 3: Initial results of Google Summer of Code 2024 announced.
• September 3 - November 4: GSoC contributors with extended timelines continue coding.
• November 4: Final date for all GSoC contributors to submit their work product and final evaluation.
• November 11: Final date for mentors to submit evaluations for GSoC contributor projects with extended deadlines.

For further details, please refer to the GSoC Timeline.

Join the Discussion 🗣️​

If you have any doubts and want to discuss something or want resources, don't forget to join our Discord server. We have a dedicated channel for GSoC named #gsoc to answer any questions.

We are incredibly excited to embark on this GSoC journey with all potential contributors, and look forward to fostering collaboration, innovation, and growth within the Uptane ecosystem. Together, let's make GSoC 2024 a resounding success! 🌱

Stay tuned for more updates and exciting developments. 📣

Greetings, Uptane community 👋!

As Google Summer of Code (GSoC) 2024 ☀️ approaches, we're thrilled to announce an open call for possible Uptane projects. One of our community members, Jon Oster, has already put forth two compelling proposals, and we're eager to expand this list with your innovative ideas. Before diving into the details of Jon's proposals, let's encourage everyone to participate in the discussion and contribute fresh perspectives on our GitHub discussion board.

Here are the current projects proposed by Jon Oster:

Proposal 1: Integrating aktualizr with Popular Embedded Software Updaters 🔄​

Aktualizr, a Uptane client written in C++, focuses on embedded Linux systems. Uptane's core functionality is vital for securing and validating software updates in highly security-sensitive and safety-critical systems. However, aktualizr currently supports only OSTree as a method for installing updates.

This GSoC project aims to enhance aktualizr by implementing support for an A/B partition-based update method. Swupdate or RAUC, two popular open-source software updaters, are the targeted integration points. While libaktualizr already supports additional package managers, our ideal solution would be a collaboration with the maintainers of Swupdate or RAUC.

Key skills required: Systems-level programming in C++

Potential mentors: Jon Oster, Patti Vacek, Phil Wise, Rogerio Borin, Phil Lapczynski, Person-to-be-named-later from SWUpdate or RAUC project.

Proposal 2: Creating an Open-Source Web UI for OTA Community Edition 🌐​

Uptane's project already boasts open-source implementations of core back-end services. However, setting up and using these services can be challenging. OTA Community Edition provides a simplified, Docker-based deployment method, but lacks a crucial component - a user-friendly UI.

This GSoC project seeks to develop a new, simplified UI from scratch and integrate it into OTA Community Edition. The goal is to enable ordinary users to interact with the system seamlessly. Additionally, the project should include a robust test suite to ensure the UI remains functional with any upstream changes in the core services.

Key skills required: Front-end/UI development, automated testing, CI/CD

Potential mentors: Jon Oster, Temi Adeyeri, [Mentor to be named]

Join the Discussion and Share Your Ideas 🗣️​

If you have any other amazing ideas to contribute, feel free to join the discussion on our GitHub board. Remember, the deadline for submitting your ideas is January 22. We encourage your participation in shaping the official project list for GSoC registrations.

Let's make Uptane GSoC 2024 ☀️ a collaborative success 🚀!

Introduction​

Greetings, fellow developers and enthusiasts! I'm Abhijay Jain, and I'm thrilled to share the incredible journey of my Google Summer of Code (GSoC) project with Uptane. In this blog, I'll walk you through the key aspects of my project, the challenges faced, the milestones achieved, and the exciting future prospects for serving its community.

Student Info 🧑‍🎓​

Before we dive into the details, let me reintroduce myself:

• Name: Abhijay Jain
• Email: Abhijay007j@gmail.com
• GitHub Profile: https://github.com/Abhijay007
• Medium: https://medium.com/@abhijay007j
• LinkedIn: https://www.linkedin.com/in/abhijay-jain-551b01193/

📙 Abstract​

Uptane is an important project that provides secure software updates for connected vehicles, and it needs to offer a better experience to its users to encourage the adoption of the technology. The project's website is the primary source of information for users and developers, and it's essential that the information is easy to access and understand. The current website has a lot of information; however, it's not well-organized. It's difficult for new users to find the essential information they need. The navigation through the site is also challenging. All of these factors could discourage new users from learning more about the project. The goal of this project is to overhaul the Uptane.io website to create a better user experience through more logical organization and easier navigation.

✉️ Communication during the development period​

Before GSoC, contributors communicated with each other either through GitHub discussions or asynchronously via email. Since GSoC needed more regular discussion (more on a personal level), we decided to have bi-weekly meetings to have seamless communication and better understanding. For text conversations, we stuck to email as it is a feasible option for text-based communication. After every meeting, I used to write a follow-up email to the mentors so that we could have a backup or a routine outline of things we have discussed in those bi-weekly meetings.

One of our very first follow-up emails.

📝 About the project​

The objective of this project is to deconstruct the current website layout and design and create a more logical arrangement of information. We aim to achieve this by:

• Improving the existing platform and overall design of the website, including typeface and color choices, to create a cleaner, more contemporary look.
• Reorganizing the content to make it easier for users to find the information they need to consider before adopting or integrating the Uptane project.
• Identifying key information that may be missing and adding it to the website.
• Adding dynamic elements to the website to support more interactivity between users and the site.

(PS: Here’s the link to my GSoC proposal if you’re interested!)

Initialization 🚀​

During our first meeting, we needed to make an important decision: whether to stick with the existing technology, which is Jekyll, or migrate the site to a new framework, Docusaurus. After a discussion, we decided to go with Docusaurus as it is quite easy to maintain and comparatively better than Jekyll. The mentors assigned me the task of testing the existing content of the site with Docusaurus so that we can determine if using this program would be feasible. So, I created a demo version of the site and shared it with the mentors. After review, both the mentors and other community members reviewed our decision to go with Docusaurus as our main framework to build the site. The mentors then suggested that I move forward and prepare a new design layout for the site.

New Site Layout📐​

I initiated the design of the new site by adopting a collaborative approach to receive continuous feedback. For efficient communication and design collaboration, I opted to use Figma, a tool with which I had prior experience. Figma served its purpose effectively. Lois shared a rough design doc linked here explaining what we need on the new site, following which I started gathering design inspiration and shared a preliminary rough layout on Figma. I explored various platforms such as Dribbble and Behance. After conducting research, I stumbled upon a valuable resource: the Docusaurus showcase, which contained a collection of open-source sites built with Docusaurus. Drawing inspiration from these sites, I began working on the site's layout. I created a preliminary design that can be viewed below

• Link to the Figma Design File : Figma Design.

Figma Design Preview

• Here is a video overview of the site, where I explained all the sections

Coding the Site 💻​

Once we had finalized the site's design to a significant extent, I embarked on the coding phase. Initially, I set up the existing site with Docusaurus boilerplate code to establish a starting point for development. Subsequently, I started coding individual components step by step, commencing with the home page and gradually extending to other sections. Throughout the development process, we engaged in iterative discussions and improvements to existing components. Some components that were initially included were reevaluated, and their significance was reconsidered, leading to a few additions and removals. Upon completion of the final layout, we proceeded with populating the site with documentation content and refining the existing codebase.

Content Improvements 📄​

After completing the initial deployment and layout of the site, we shifted our focus to enhancing the content, which serves as the documentation for the Uptane community. In the existing site, we encountered several content-related issues. Firstly, there was an abundance of unnecessary content including a number of redundancies across the site, and secondly, some of the existing content was outdated and required substantial improvements.

In the new site, we undertook a comprehensive overhaul of the documentation structure and redefined the hierarchy. This restructuring presented us with some challenges, especially when dealing with content originally structured for the old Jekyll architecture. We needed to adapt this content to the Docusaurus-based Markdown format. Docusaurus treats Markdown files somewhat differently and provides helpful tools for managing content effectively.

Some content on the site is fetched from different repositories. Initially, we contemplated establishing a workflow to handle this content, but over time, we realized that we could optimize the process by making edits to the existing workflows and ensuring that the updated content adheres to Docusaurus standards and best practices.

For details on the specific commits related to these content improvements, please refer to this link.

Important Links 🔗​

For those curious minds, here are essential links to explore:

• GSoC Project Page
• GSoC Project Proposal
• GitHub Organization Repo
• GitHub Personal Repo
• GitHub Project Demo Repo
• Commits during GSoC 2023 in Demo Repo
• Commits during GSoC 2023 in Main Repo - UptaneDocusaurus Branch
• Website DEMO Deployed Version
• Website Live Deployed Version

Interactions with the Uptane Community 🤝​

I had the privilege of presenting myself and my GSoC project to the Uptane community at an Uptane workshop on June 23rd. During this presentation, I introduced myself and provided an overview of my GSoC project. Initially, I felt a bit nervous, and there were moments of hesitation during my presentation. However, the Uptane community and my mentors were incredibly supportive, and my efforts seemed to be appreciated.

I received valuable assistance from Lois in preparing the initial presentation, and she also provided timely reviews, which greatly contributed to the success of my presentation. This experience was entirely new to me, and it was an excellent opportunity to interact with members of the Uptane community, many of whom are highly accomplished in their respective fields. Presenting my work in front of such a distinguished audience was both a valuable experience and a unique opportunity for me. I am grateful to all the GSoC mentors who granted me this chance to showcase my work to the community.

If you would like to access the presentation slides, you can find them here.

⭐ Acknowledgements 🙏​

My journey through Google Summer of Code has been a remarkable experience as it represented a transition from personal projects to contributing to real-world website applications. The opportunity to learn by doing has been invaluable, and I am deeply grateful to have been part of this extraordinary program ❤️.

I extend my heartfelt gratitude to all the mentors who have been an incredible source of guidance and support throughout my GSoC journey. Your mentorship has been instrumental in my growth as a developer, and I am fortunate to have had you by my side every step of the way.

I want to express my appreciation to all the mentors, including Lois, Philip, Ira, Jon, Justin, and the dedicated members of the community. Your unwavering support and willingness to assist have been invaluable. The regular check-in meetings, understanding of contributors' needs, and effective program structuring were all testaments to your dedication. You maintained open lines of communication through emails, which facilitated the sharing of progress and concerns. I couldn't have asked for better mentors; you have truly made my GSoC journey special and enriched my experience.

To the reader who has made it this far, I want to express my gratitude. It's the support and recognition of fellow developers like you that make our efforts all the more rewarding. Thank you for being a part of this journey with me.

What Was Covered ✔️​

The project successfully achieved milestones, including migration to Docusaurus, documentation revision, redesigned website layout, enhanced design elements, addition of missing information, and integration of dynamic elements.

What Work Remains 🚀​

While most project milestones were met, exciting improvements lie ahead. Integration of site analytics, enhanced search functionality, introduction of new components, code and image optimization, and workflows for auto-updating content and PR previews are among the future prospects.

Reference 📚​

For those interested in diving deeper, here are references to explore:

• Docusaurus Documentation
• Docusaurus Showcase
• Figma
• Uptane Site
• React Documentation

Overall Experience 😄​

To say the least, this has been a highly rewarding experience. I extend my most sincere gratitude to Google for running such a great and extremely inclusive program, Google Summer of Code has been a great opportunity for me. I learned new technical concepts every day and it has made me a stronger software developer today. I had a wonderful time interacting with the amazing folks at Uptane and especially it has been an absolute pleasure working with my mentors. They have been constantly guiding and helping me throughout this journey, undoubtedly the best mentors anyone could ever ask for!

Truly an experience I will cherish for a lifetime!

🔄 Would like to sync? 📞​

• We are keeping all the communications open, so that everyone can sync and is free to contribute. So if you have any feature/bugs suggestions about anything please do not hesitate to open up an issue in the Uptane Projects.

• You can join Uptane's mailing list to participate in the discussions happening here : uptane-standards@googlegroups.com. Additionally, you can connect with the Uptane community on Discord, or stay updated on the latest announcements by following Uptane on LinkedIn.

As winter approaches, Uptane is thrilled to announce its participation in the annual 24 Pull Requests event! Joining this initiative is a testament to our project's continuing commitment to collaboration and community building.

🤝 About Uptane:​

Uptane is a robust framework designed to fortify the security of software updates within the automotive industry. It addresses the growing need for a reliable solution that can ensure the safety and integrity of software updates for vehicles.

🎁 24 Pull Requests:​

The 24 Pull Requests event is an annual community-organized celebration in which developers are invited to contribute to open source projects over the holiday season. Join us in spreading the joy of collaboration by submitting 24 pull requests between December 1 and December 24.

🚀 How You Can Contribute:​

Uptane welcomes developers from around the globe 🌍 to be a part of this exciting opportunity. Whether you're a seasoned contributor or someone eager to make their first open-source contribution, there's a place for you in the Uptane community. Collaboration is at the core of Uptane's values, and we can't wait to review and merge your pull requests!

📆 Mark Your Calendar:​

Save the dates between December 1 and December 24 for 24 Pull Requests. The 24 Pull Requests web-app/website offers information about the event, project details, and a calendar to visualize your contributions.

Let's come together, share our knowledge, and make a positive impact on the future of automotive software. Fork the Uptane repository, submit your pull requests, and let's make this holiday season a season of giving in the open-source spirit! 🎄🛠️

Cheers to secure software updates, collaborative coding, and a festive season of open source! 🎉☕

Introduction​

Uptane, the pioneering software update security system for the automotive industry, recently took a significant leap in its community engagement efforts. Following the launch of our revamped website, a project that was part of the Google Summer of Code, we decided to participate in Hacktoberfest. This decision, suggested by one of our core website contributors, Abhijay Jain, marked a strategic step in leveraging our recent advancements, and further solidifying our presence in the open-source community. Our initial announcement about participating in Hacktoberfest can be found in our previous blog post.

Participation in Hacktoberfest: Goals and Strategy​

Our primary goal for participating in Hacktoberfest was twofold: to grow our vibrant open-source community and to address the lingering issues from our website's transition. With a new site comes new challenges, and we saw Hacktoberfest as an ideal platform to engage with skilled contributors who could help us refine and polish our online presence.

Community Engagement: Discord, GitHub, and Beyond​

Community engagement was at the heart of our Hacktoberfest strategy. Our core community members played a crucial role in creating and managing issues, reviewing pull requests, and facilitating meaningful interactions with contributors. We leveraged Discord for real-time communication and discussions, while GitHub's robust communication tools were instrumental in managing our project workflows. This integrated approach allowed for efficient and effective collaboration, making the most of the talents and enthusiasm of the open-source community.

Contributions: Diverse and Impactful​

During Hacktoberfest, Uptane received a variety of contributions that significantly enhanced our project. We were thrilled to see 14 pull requests, each addressing a separate issue. These ranged from simple textual improvements to our website to the setting up advanced Continuous Integration (CI) workflows and automations for our repository. This diversity in contributions reflects the breadth of skills and dedication within our community. A detailed list of the resolved issues can be found here. Special thanks to our Hacktoberfest contributors, Tejas Raskar, Shubham Sharma, Ashmit JaiSarita Gupta, Mik Watkins, Anuj Mittal, Ojas Mittal, and Abhijay Jain!

Challenges and Successes: Managing a Wave of Contributions​

One of the biggest challenges we encountered during Hacktoberfest was effectively managing the influx of contributions. With a high level of engagement from the community, it was crucial to maintain a steady pipeline of open issues for contributors to work on. Our core Uptane team worked tirelessly to ensure that contributors had clearly defined issues and tasks. These tasks were scoped into bite-sized, achievable goals suitable for a single pull request. This approach not only streamlined the contribution process but also ensured that each contribution was meaningful and impactful.

Impact on Uptane and Future Plans: A Resounding Success and Looking Forward​

The results of Hacktoberfest have been overwhelmingly positive for Uptane. The event not only brought in significant contributions that enhanced our project but also strengthened our ties with the open-source community. Encouraged by this success, we are eagerly looking forward to participating in similar events in the future. To make our future endeavors even more successful, we're actively seeking suggestions for community events akin to Hacktoberfest. We invite everyone to join the discussion and share their ideas here!

Closing Remarks: An Invitation to Collaborate​

As we reflect on our Hacktoberfest experience, we are filled with gratitude for the vibrant community that surrounds Uptane. Your contributions, suggestions, and engagement are what drive us forward. We invite you to continue this journey with us, whether by contributing to our projects, participating in discussions, or simply sharing your ideas. Together, we can continue to make Uptane not just a robust security system for automotive software updates but also a thriving example of collaborative success in the open-source world.

As the leaves change color 🍂 and the breeze carries a hint of chill, the open-source community gears up for a month of code, collaboration, and coffee-fueled late nights ☕. Hacktoberfest, the annual open-source celebration, is here again, and this year, Uptane is joining the fray!

Uptane, a robust framework designed to secure software updates for automobiles 🚗, is participating in Hacktoberfest 2023 to foster community engagement and encourage contributions to its project. With cybersecurity becoming a paramount concern in the automotive industry, the initiative taken by Uptane is a timely and significant one.

This Hacktoberfest, developers from around the globe 🌍 can contribute to Uptane's repository, helping to enhance the security framework and make vehicles more secure. Whether you're a seasoned developer or a newbie looking to make your first open-source contribution, Uptane welcomes you with open arms 🤗.

The Uptane community values collaboration and is excited to review and merge your pull requests. So, grab your favorite brew ☕, fork the Uptane repository, and let's secure the future of automotive software, one pull request at a time! 🛠️

• Introduction
• Selection Process
• About Uptane
• Brief Intro to My Project
• Community Bonding Period
• Week 1 Task: Coding Phase
• What's Next?
• Conclusion

Introduction

Hi Everyone 👋

Welcome to the GSoC'23 Blogs Index 0! This is the first blog of a GSoC series where I'll be sharing my entire journey as a contributor and student developer, from day zero to the project's completion. I'm excited to have you join me on this adventure.

Before we delve into the details, let me first introduce myself, I'm Abhijay Jain, a computer science student from India currently pursuing B-Tech. My specialization lies in front-end development and web-related technologies. I have a keen interest in open-source projects and have collaborated with various organizations, such as Fossaisa, JBoss, Layer5, Mexili, P5.js-sound, Script Foundation, Open Horizon, SCoRe Labs, and EtherealEngine. In the spring of 2022, I had the opportunity to contribute to Open Horizon as an LFX mentee, I worked as a GSoC'22 student with SCoRe Lab, and currently, I'm contributing to Ethereal Engine as an XROS fellow'23, and now working with Uptane as a GSoC'23 student.

In this blog post, I'll share how my GSoC journey started, including the application process and my experiences during the community bonding period. I'll also provide an overview of my activities during the first week of the coding phase. Let's get started!

But why am I documenting this journey?

Good documentation is the key to effective collaboration. It provides a solid foundation for fostering innovation and driving progress. Not only does it serve as a valuable resource for reflection and learning, but it also helps us navigate through past experiences with clarity and relevance.

So let's talk about the selection progress and know little bit about GSoC as program as well.

Selection Process: How I got selected

In March, GSoC announced the open-source organizations participating in the program on their website. These organizations are seeking developer and provide project details. Interested individuals then submit detailed proposals outlining their project plans before the April deadline. Mentors from participating organizations evaluate the proposals, and the selected contributors are announced in May. After the selection process, the official coding period begins.

Most of you are quite familiar with or heard about the overall selection process for Google Summer of Code. If you aren't, then don't worry, I will write a detailed post about the selection process in an upcoming blog.

Having been a GSoC student in the past, I was familiar with the process. However, this year, I wasn't sure if I would apply or not as I hadn't looked into projects extensively. I applied to Uptane, a project I stumbled upon while reading about Linux Foundation projects. The project that caught my attention was called "Overhauling Uptane.io: Creating a Better User Experience for the Uptane Project Website." It involved revamping the current Uptane site, adding new features, and improving its overall appearance.

I applied to this project as I have previous experience with a similar tech stack and worked on documentation during my time in Open Horizon as an LFX mentee. I believe that this project could be impactful and provides an opportunity to create something that can be used as a resource by developers. If you want to read about the idealist in detail, you can refer to here.

Although I applied a little late, my mentor Lois Anne DeLong was incredibly supportive and helped me review my proposal. Despite the timing, I was fortunate enough to be selected for GSoC 2023 based on the quality of my proposal.

But before we delve into the details of my project, let's talk about the Uptane organization itself.

About Uptane: A short brief

Uptane is an open and secure software update framework designed to protect software delivered over-the-air to automobile electronic control units (ECUs). This framework provides protection against malicious actors who can compromise servers and networks used to sign and deliver updates. Uptane is integrated into Automotive Grade Linux, an open-source system used by many large OEMs, and has been adopted by several U.S. and international manufacturers.

Uptane was created in 2016 through a collaboration between NYU, UMTRI, SwRI, and automotive industry experts. It uses the basic design principles of TUF, which is used in many production software update systems.

According to Wikipedia, "Uptane is a Linux Foundation / Joint Development Foundation hosted software framework designed to ensure that valid, current software updates are installed in adversarial environments. It establishes a process of checks and balances on these electronic control units (ECUs) to ensure the authenticity of incoming software updates. Uptane is designed for 'compromise-resilience,' limiting the impact of a compromised repository, insider attacks, leaked signing keys, or similar attacks. It can be incorporated into most existing software update technologies, offering particular support for over-the-air programming or OTA programming strategies."

Now, let's get into a brief introduction to my GSoC'23 project.

Brief Intro: Overhauling Uptane

My GSoC'23 project involves enhancing the documentation website for Uptane. The main objective is to make the site more user-friendly, visually appealing, and accessible. By improving the documentation and the overall user experience, we aim to encourage wider adoption of Uptane and ensure a smooth onboarding process for developers and contributors.

The project's website serves as the primary source of information for users and developers, and it's essential that the information be easily accessible and understandable. However, the current website lacks organization and intuitive navigation, which could potentially discourage new users from adopting the system. Therefore, the goal of my project is to create a better user experience through improved organization and navigation.

After carefully reading and understanding the project's requirements and proposed ideas, I prepared my proposal accordingly. The proposal covered the project objectives, goals, proposed ideas, deliverables, and more. It also explored alternate approaches, such as using different frameworks like Docusaurus, if necessary.

If you're interested in reading my full proposal in detail, you can find it here.

Once the selected contributors were announced in May, we entered the community bonding period, which allowed us to establish connections with our mentors and get familiar with the organization.

Community Bonding: Mentor Meeting & Task Breakdown Finalization

After being selected for GSoC, the community bonding period began in May. This phase allows GSoC contributors to establish connections with their mentors and get familiar with the organization. During the community bonding period, I had the pleasure of connecting with my mentor, Lois, and other members of the Uptane community. Our initial call played a vital role in establishing a strong foundation for our collaboration. We discussed various important aspects, including:

• Meeting Schedule: We established a regular meeting schedule that suited everyone involved. This ensured consistent communication throughout the project.
• Priorities: We identified key tasks that needed to becompleted and established their order of importance. This helped us prioritize our work and stay on track.
• Project Timeline: To ensure alignment with the GSoC review dates, we created a rough timeline that outlined the project's deadlines and milestones. This provided us with a clear roadmap to follow.
• Engaging the Uptane Community: We explored different ways to engage with the larger Uptane community, such as participating in online exchanges, contributing to blog posts, and more. This ensured that our work had a wider impact and fostered collaboration within the community.

One of the significant outcomes of our meeting was the decision to evaluate the use of Jekyll versus Docusaurus for revamping the site. After considering various factors and insights from mentors like Philip, Ira, Justin, and Andre, we concluded that Docusaurus would be the ideal choice. However, before fully committing to Docusaurus, we needed to ensure its compatibility with the existing Uptane documentation and address web accessibility concerns.

With our tasks and objectives defined, my mentor assigned me the initial task of creating a demo version of the site using Docusaurus. This basic version aimed to test the compatibility of the existing Uptane documentation with Docusaurus. I set up Docusaurus locally and migrated the Uptane docs to the new environment. Most of the markdown files seamlessly integrated with Docusaurus, requiring minimal adjustments. The demo version serves as a starting point for further enhancements.

After a week of the community bonding period, the official coding phase began on May 29th.

Week 1 Task: Coding Phase (from May 29th onwards) | Initializing the project

During the first week of the coding phase, my primary task was to work on the demo version of the site. The goal was to determine if the existing Uptane docs are compatible with Docusaurus or if we should consider sticking with Jekyll, as discussed in our initial community call. I set up Docusaurus locally and migrated the Uptane docs to this new environment. The current state of the site is still quite basic, consisting of boilerplate code provided by Docusaurus along with the existing Uptane docs.

For creating the demo version of the site, I referred to the official documentation of Docusaurus.

To break down this task in simple words, I tested the existing markdown files present in the current repo with the boilerplate code of Docusaurus and made sure if it is compatible or not.

While most of the markdown files integrated smoothly with Docusaurus, requiring minimal adjustments, there is still work to be done to enhance the overall functionality and design of the site.

Docusaurus boilerplate code provides a project folder structure for managing docs, blogs, src file (like CSS or pages). It also contains a Docusaurus.config file which allows developers to configure Docusaurus according to their needs.

If you're curious to see the progress made so far and experience the demo version of the site, feel free to check it out here. Keep in mind that the demo version may contain broken links or incomplete markdown files. To address this issue, we plan to implement a workflow that identifies broken links or orphan pages, ensuring that the documentation remains relevant and users encounter fewer 404 errors.

I shared the demo version of the site with my mentors, along with the code repository (currently private). After careful consideration, we collectively decided to proceed with Docusaurus as it offers ease of maintenance, utilizes the latest technologies, and provides a more accessible and user-friendly experience. Moreover, Docusaurus allows us to build an ecosystem by integrating various modern tools, which would be challenging with Jekyll.

What's Next?

During our second community call, we discussed the tasks for the second week. In our call, we focused specifically on the design aspect of the site after the demo version. I suggested that all mentors visit the Docusaurus Showcase website to gather inspiration from existing sites regarding navigation, hero sections, footers, and other content. By sharing your valuable suggestions, we can collectively create compelling designs. Our goal is to achieve an attractive landing page before the first evaluation to make our site more presentable and engaging.

One of the mentors, Jon, shared crucial points regarding getting Docusaurus working with a multi-instance build. He mentioned that the deployment considerations are present in a separate repository. It would be great if we could directly fetch the deployment considerations from that repository and set up CI/CD pipelines for both deployment and pull requests.

To summarize the tasks for the upcoming weeks:

• Create a compelling design incorporating mentor feedback.
• Find a way to make Docusaurus work with a multi-instance build and set up CI/CD pipelines accordingly.

In addition to these tasks, we have an Uptane workshop scheduled for June 23. As a GSoC contributor, I am grateful for the opportunity to present my GSoC project in front of the Uptane community. During this presentation, I will provide an overview of the project, discuss what we aim to achieve, and share the progress made up until the workshop.

Conclusion

In conclusion, the journey of GSoC'23 has begun, and I'm thrilled to share my experiences as a contributor and student developer with all of you. This blog marks the beginning of a series where I'll be documenting my entire journey, from day zero to the completion of the Uptane documentation website project.

Stay tuned for the upcoming blog posts, where I'll be sharing more about the development process, milestones, challenges faced, and the exciting enhancements we make to the Uptane documentation website.

Thank you for joining me on this incredible journey, and I look forward to sharing more updates with you soon!