Grapesss: a physical Shamir's Secret Sharing application [ESP32-C3 + Mobile] by ecandino

Description

A couple of years ago I created StegoSecretS, a small cli used to encrypt and split a secret into multiple keys, using the Shamir's Secret Sharing algorithm.

The idea is to re-implement the project using physical devices. One device alone will be useless, but when close together they can be used to decrypt the secret.

On a practical side the user encrypts the secret with a mobile application. The same application is used to split the secret, and load the partial keys into different micro-controllers. Another user will be able to decrypt the secret only having at least N devices close together (using the application).

I'm planning to use a couple of ESP32-C3 I bought, and build a very simple Android mobile application.

Goals

• Learn about Rust and micro-controllers (ESP32-C3)
• Learn about mobile applications (Android and Kotlin)

Resources

• Shamir's Secret Sharing
• The esp-rs Book
• Android - Kotlin

---

Write an url shortener in Rust (And learn in the way) by szarate

So I have 469.icu :), it's currently doing nothing... (and for sale) but in the meantime, I'd like to write an url shortener from scratch and deploy it on my own server

https://github.com/foursixnine/url-manager-rs/tree/main

---

Agama installer on-line demo by lslezak

Description

The Agama installer provides a quite complex user interface. We have some screenshots on the web page but as it is basically a web application it would be nice to have some on-line demo where users could click and check it live.

The problem is that the Agama server directly accesses the hardware (storage probing) and loads installation repositories. We cannot easily mock this in the on-line demo so the easiest way is to have just a read-only demo. You could explore the configuration options but you could not change anything, all changes would be ignored.

The read-only demo would be a bit limited but I still think it would be useful for potential users get the feeling of the new Agama installer and get familiar with it before using in a real installation.

As a proof of concept I already created this on-line demo.

The implementation basically builds Agama in two modes - recording mode where it saves all REST API responses and replay mode where it for the REST API requests returns the previously recorded responses. Recording in the browser is inconvenient and error prone, there should be some scripting instead (see below).

Goals

• Create an Agama on-line demo which can be easily tested by users
• The Agama installer is still in alpha phase and in active development, the online demo needs to be easily rebuilt with the latest Agama version
• Ideally there should be some automation so the demo page is rebuilt automatically without any developer interactions (once a day or week?)

TODO

• Use OpenAPI to get all Agama REST API endpoints, write a script which queries all the endpoints automatically and saves the collected data to a file (see this related PR).
• Write a script for starting an Agama VM (use libvirt/qemu?), the script should ensure we always use the same virtual HW so if we need to dump the latest REST API state we get the same (or very similar data). This should ensure the demo page does not change much regarding the storage proposal etc...
• Fix changing the product, currently it gets stuck after clicking the "Select" button.
• Move the mocking data (the recorded REST API responses) outside the Agama sources, it's too big and will be probably often updated. To avoid messing the history keep it in a separate GitHub repository
• Allow changing the UI language
• Display some note (watermark) in the page so it is clear it is a read-only demo (probably with some version or build date to know how old it is)
• Automation for building new demo page from the latest sources. There should be some check which ensures the recorded data still matches the OpenAPI specification.

Changing the UI language

This will be quite tricky because selecting the proper translation file is done on the server side. We would probably need to completely re-implement the logic in the browser side and adapt the server for that.

Also some REST API responses contain translated texts (storage proposal, pattern names in software). We would need to query the respective endpoints in all supported languages and return the correct response in runtime according to the currently selected language.

Resources

• Agama sources
• Experimental proof of concept demo
• The respective source code change

---

Hacking on sched_ext by flonnegren

Description

Sched_ext upstream has some interesting issues open for grabs:

• core event counters
• topology: Use cpumasks

Goals

Send patches to sched_ext upstream

Also set up perfetto to trace some of the example schedulers.

Resources

https://github.com/sched-ext/scx

---

SMB3 Server written entirely in Rust by dmulder

Description

Given the number of bugs frequently discovered in the Samba code caused by memory issues, it makes sense to re-write the smbd service purely in Rust code. Meanwhile, it would be wise to abandon backwards compatibility here with insecure protocol versions, and simply implement the SMB3 spec.

Goals

Get a simple server up and running and get it merged into upstream Samba (which now has Rust build support).

Resources

---

file-organizer: A CLI Tool for Efficient File Management by okhatavkar

Description

Create a Go-based CLI tool that helps organize files in a specified folder by sorting them into subdirectories based on defined criteria, such as file type or creation date. Users will pass a folder path as an argument, and the tool will process and organize the files within it.

Goals

• Develop Go skills by building a practical command-line application.
• Learn to manage and manipulate files and directories in Go using standard libraries.
• Create a tool that simplifies file management, making it easier to organize and maintain directories.

Resources

• Go Standard Libraries: Utilize os, filepath, and time for file operations.
• CLI Development: Use flag for basic argument parsing or consider cobra for enhanced functionality.
• Go Learning Material: Go by Example and The Go Programming Language Documentation.

Features

• File Type Sorting: Automatically move files into subdirectories based on their extensions (e.g., documents, images, videos).
• Date-Based Organization: Add an option to organize files by creation date into year/month folders.
• User-Friendly CLI: Build intuitive commands and clear outputs for ease of use. This version maintains the core idea of organizing files efficiently while focusing on Go development and practical file management.

---

suse-rancher-supportconfig by eminguez

Description

Update: Live at https://github.com/e-minguez/suse-rancher-supportconfig I finally didn't used golang but used gum instead

SUSE's supportconfig support tool collects data from the SUSE Operating system. Rancher's rancher2_logs_collector.sh support tool does the same for RKE2/K3s.

Wouldn't be nice to have a way to run both and collect all data for SUSE based RKE2/K3s clusters? Wouldn't be even better with a fancy TUI tool like bubbletea?

Ideally the output should be an html page where you can see the logs/data directly from the browser.

Goals

• Familiarize myself with both supportconfig and rancher2_logs_collector.sh tools
• Refresh my golang knowledge
• Have something that works at the end of the hackweek ("works" may vary )
• Be better in naming things

Resources

All links provided above as well as huh

---

Jenny Static Site Generator by adam.pickering

Description

For my personal site I have been using hugo. It works, but I am not satisfied: every time I want to make a change (which is infrequently) I have to read through the documentation again to understand how hugo works. I don't find the documentation easy to use, and the structure of the repository that hugo requires is unintuitive/more complex than what I need. So, I have decided to write my own simple static site generator in Go. It is named Jenny, after my wife.

Goals

• Pages can be written in markdown (which is automatically converted to HTML), but other file types are also allowed
• Easy to understand and use
  • Intuitive, simple design
  • Clear documentation
  • Hot reloading
  • Binaries provided for download
• Future maintenance is easy
  • Automated releases

Resources

https://github.com/adamkpickering/jenny

---

Implement a CLI tool for Trento - trentoctl by nkopliku

Description

Implement a trentoctl CLI for interacting with a trento installation

Goals

• learn rust
• implement an initial trentoctl tool to enhance trento automation
• have fun

Resources

trento rust. TUIs listed on this other hackweek project Hack on rich terminal user interfaces

---

Dartboard TUI by IValentin

Description

Our scalability and performance testing swiss-army knife tool Dartboard is a major WIP so why not add more scope creep? Dartboard is a cli tool which enables users to:

• Define a "Dart" config file as YAML which defines the various components to be created/setup when Dartboard runs its commands
• Spin up infrastructure utilizing opentofu/terraform providers
• Setup K3s or RKE2 clusters on the newly created infrastructure
• Deploy Rancher (with or without downstream cluster), rancher-monitoring (Grafana + Prometheus)
• Create resources in-bulk within the newly created Rancher cluster (ConfigMaps, Secrets, Users, Roles, etc.)
• Run various performance and scalability tests via k6
• Export/Import various tracked metrics (WIP)

Given all these features (and the features to come), it can be difficult to onboard and transfer knowledge of the tool. With a TUI, Dartboard's usage complexity can be greatly reduced!

Goals

• Create a TUI for Dartboard's "subcommands"
• Gain more familiarity with Dartboard and create a more user-friendly interface to enable others to use it
• Stretch Create a TUI workflow for generating a Dart file

Resources

https://github.com/charmbracelet/bubbletea

---