This section is the engineering design for Devora’s role in the Linux boot sequences. We will look into various design aspects.
Boot Sequences Design
Devora has an additional process to the current Linux boot sequences, complying to its 1st design principle. This is the design diagram:
In general, Devora plays 2 main roles:
- Seek out keyfile and load it into cryptsetup.
- Update USB stick bootloader before letting user know to unmount the USB stick gracefully.
Devora project only introduces the addition process blocks for the OS.
Devora only get triggered by 2 processes:
- cryptsetup triggers Devora searching for keyfile.
- bash profile triggers Devora to update the USB stick
For cryptsetup keyfile seeking process, the fail-safe is always fallback to the common user manual input.
/boot update, the fail-safe process is to handle the user experience
for unmounting process.
These are the data management for Devora’s implementation. We are looking into 2 different form-factors: the USB stick acting as a key while the machine acting as the lock.
|Attributes||USB Stick||Operating Machine|
|Data Type||Storing Decryption Key and ||Storing Devora Binary|
|Data At Rest||Keyfile: encrypted||Comply to Disk Encryption|
|Data In Motion||Keyfile: encrypted form||Comply to |
|Permission||Read only||Read only|
|Access Privilege||Root||Root, User|
|Capability||Read only||Read (Root, User) and Write (Root)|
|Ecryption Cipher||Compy to Disk Encryption|
|File Location||Keyfile: |
|Partition Types||FAT32 for ||Comply to OS (e.g. Ext4)|
|Default Nature||Removable||binded to compute module|
|Recommended Usage||Booting and Update: only bind|
Otherwise: stay detached and stored safely
|normal computing usage|
These are the tools selected for developing Devora.
Go programming language is selected as main language due to its single binary compilation nature. This fulfills the Design Principle #3 - Single Binary.
Fennec project is used to automate the project. It has Go 1.12 supports which mitigate most of the Go library issues.
There are 2 technologies we are currently using:
- Hugo - Extended - for documentations rendering.
- Bissetii - for serving as content templates and documentationg engine.
Since this is a core system application, the proposed packaging format would be:
- Red Hat
Others like Snapcraft and Flatpak are not a suitable candidiates.