mirre-mt/masters-thesis
Archived
1
0
Fork 0
Code Releases 1 Activity

tex: corrections

Browse Source
This commit is contained in:
leo 2023-05-24 22:49:56 +02:00
parent 2eee20d749
commit b0e73b7294
Signed by: wanderer
SSH Key Fingerprint: SHA256:Dp8+iwKHSlrMEHzE3bJnPng70I7LEsa3IJXRH/U+idQ
1 changed files with 34 additions and 37 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

71
tex/text.tex
View File

@ -17,10 +17,6 @@ Introduce the goals and the methods attempted to achieve the goals.
% =========================================================================== %
\part{Theoretical part}
\n{1}{Purpose}
What this write-up is attempting to achieve.
\n{1}{Terminology}
\n{2}{Linux}
@ -52,10 +48,9 @@ points, process IDs, user and group IDs, Cgroups and others) that differs for
each different set of processes, similar in thought to FreeBSD
\emph{jails}~\cite{freebsdjails} with the distinction being that they are, of
course, facilitated by the Linux kernel namespace
functionality~\cite{linuxnamespaces}, which is in turn be regarded to be
functionality~\cite{linuxnamespaces}, which is in turn regarded to be
\emph{inspired} by Plan 9's namespaces~\cite{plan9namespaces}, Plan 9 being a
Bell Labs successor to Unix 8th Edition, discontinued in 2015.
While there without a doubt \emph{is} specificity bound to using each of the
tools that enable creating (Podman vs.\ Buildah vs.\ Docker BuildX) or running
(ContainerD vs.\ runC vs.\ crun) container images, when describing an action
@ -63,6 +58,7 @@ that gets performed with or onto a container, the process should generally be
explained in such a way that it is repeatable using any spec-conforming tool
that is available and \emph{intended for the job}.
\vspace*{-\baselineskip}
\n{2}{The program}
By \emph{the program} or \emph{the application} without any additional context
@ -358,7 +354,7 @@ of writing) installation of \textit{Arch Linux (by the way)} using a
\n{1}{Development}
The source code of the project was being versioned since the start using the
The source code of the project was being versioned since the start, using the
popular and industry-standard git (\url{https://git-scm.com}) source code
management (SCM) tool. Commits were made frequently and, if at all possible,
for small and self-contained changes of code, trying to follow sane commit
@ -372,7 +368,7 @@ in fact the default in author's \texttt{.gitconfig}).
Since git allows cryptographically \emph{singing} all commits, it would be
unwise not to take advantage of this. For the longest time, GPG was the only
method available for signing commits in git, however, that is no longer
method available for signing commits in git; however, that is no longer
applicable~\cite{agwagitssh}. These days, it is also possible to both sign and
verify one's git commits (and tags!) using SSH keys, namely those produced by
OpenSSH (the same ones that can be used to log in to remote systems). The
@ -407,9 +403,9 @@ file is using the configuration value \texttt{gpg.ssh.allowedsignersfile} and
finally the configuration value of the \texttt{gpg.format} field needs to be
set to \texttt{ssh}.
Since git allows the configuration values to be local to each repository, both
of the mentioned issues can be solved by running the following commands from
inside of the cloned repository:
Because git allows the configuration values to be local to each repository,
both of the mentioned issues can be solved by running the following commands
from inside of the cloned repository:
\begin{figure}[h]
\centering
@ -451,7 +447,7 @@ self-hosted, including the workers. The tool of choice there was Drone
(\url{https://drone.io}) and the ``docker'' runner (in fact it runs any OCI
container) was used to run the builds.
The way this runner works is it creates an ephemeral container for every
The way this runner works is that it creates an ephemeral container for every
pipeline step and executes given \emph{commands} inside of it. At the end of
each step the container is discarded, while the repository, which is mounted
into each container's \texttt{/drone/src} is persisted between steps, allowing
@ -464,9 +460,9 @@ The entire configuration used to run the pipelines can be found in a file named
workflow consists of four pipelines, which are run in parallel. Two main
pipelines are defined to build the frontend assets, the \texttt{pcmt} binary
and run tests on \texttt{x86\_64} GNU/Linux targets, one for each of Arch and
Alpine (version 3.17). These the two pipelines are identical apart from
OS-specific bits such as installing a certain package, etc. For the record,
other OS-architecture combinations were not tested.
Alpine (version 3.17). These two pipelines are identical apart from OS-specific
bits such as installing a certain package, etc. For the record, other
OS-architecture combinations were not tested.
A third pipeline contains instructions to build a popular static analysis tool
called \texttt{golangci-lint}, which is sort of a meta-linter, bundling a
@ -504,12 +500,12 @@ available git server operated by the author, the reasoning \emph{pro}
self-hosting being that it is the preferred way of guaranteed autonomy over
one's source code, as opposed to large silos owned by big corporations having a
track record of arguably not always deciding with user's best interest in mind
(although recourse has been observed~\cite{ytdl}), acting on impulse or under
public pressure (potentially at least temporarily disrupting their user's
operations), thus not only beholding their user to their lengthy \emph{terms of
service} that \emph{can change at any time}, but also factors outside their
control. Granted, decentralisation can take a toll on discoverability of the
project, but that is not a concern here.
(although recourse has been observed~\cite{ytdl}). When these providers act on
impulse or under public pressure they can potentially at least temporarily
disrupt their user's operations, thus not only beholding their user to their
lengthy \emph{terms of service} that \emph{can change at any time}, but also
factors outside their control. Granted, decentralisation can take a toll on
discoverability of the project, but that is not a concern here.
The git repository containing source code of the \texttt{pcmt} project:\\
\url{https://git.dotya.ml/mirre-mt/pcmt.git}.
@ -553,7 +549,7 @@ application?'} might arise, so the following few lines will try to address
that.
Go~\cite{golang} (or \emph{Golang} for SEO-friendliness) is a strongly typed,
high-level \emph{garbage collected}, language where functions are first-class
high-level \emph{garbage collected} language where functions are first-class
citizens and errors are values.
The appeal for the author comes from a number of features of the language, such
@ -567,8 +563,8 @@ formatting question} (i.e.\ where to put the braces, tabs vs.\ spaces, etc.),
most of the discussions on this topic have been foregone. Every
\emph{gopher}~\footnote{euph.\ a person writing in the Go programming language}
is expected to format their source code with the official formatter
(\texttt{gofmt}), which automatically ensures the code adheres to the official
formatting standards.
(\texttt{gofmt}), which automatically ensures that the code adheres to the
official formatting standards.
\n{2}{A word about Nix}
\url{https://builtwithnix.org/}
@ -619,7 +615,7 @@ The configuration schema was at first being developed as part of the main
project's repository, before it was determined that it would benefit both the
development and overall clarity if the schema lived in its own repository (see
Section~\ref{sec:repos} for details). This enabled it to be independently
developed and versioned and only pulled into the main application whenever it
developed and versioned, and only pulled into the main application whenever it
is determined the application is ready for it.
The full schema with type annotations can be seen in
@ -870,7 +866,7 @@ ever attempted.
The author has additionally considered the thought of utilising an embedded
immutable database like immudb (\url{https://immudb.io}) for record keeping
(verifiably storing data change history) and additional data integrity checks,
e.g.\ for tamper protection purposes and similar, however, that work remains
e.g.\ for tamper protection purposes and similar; however, that work remains
yet to be materialised.
@ -912,7 +908,7 @@ and should therefore only be able to perform the following actions:
Let us consider a case when a user manages self, while demoting from
administrator to a regular user is permitted, promoting self to be an
administrator would constitute a \emph{privilege escalation} and likely be a
precursor to a at least a \emph{denial of service} of sorts.
precursor to at least a \emph{denial of service} of sorts.
\n{2}{Zero trust principle}
@ -922,8 +918,8 @@ precursor to a at least a \emph{denial of service} of sorts.
There is no way for the application (and consequently, the in-application
administrator) to read user's data. This is possible by virtue of encrypting
the pertinent data before saving them in the database by a state-of-the-art
\emph{age} key~\cite{age} (backed by X25519~\cite{x25519rfc7748}), which is in
turn safely stored encrypted by a passphrase that only the user controls. Of
\emph{age} key~\cite{age} (backed by X25519~\cite{x25519rfc7748}), which in
turn is safely stored encrypted by a passphrase that only the user controls. Of
course, the user-supplied password is run by a password based key derivation
function (PBKDF) before letting it encrypt the \emph{age} key.
@ -935,7 +931,7 @@ password (because they set it), which would subsequently give them unbounded
access to any future encrypted data, as long as they would be able to maintain
their database access. This is why the \emph{age} key generation and protection
are bound to the first password change. Of course, the evil administrator could
just perform the change themselves, however, the user would at least be able to
just perform the change themselves; however, the user would at least be able to
find those changes in the activity logs and know not to use the application.
But given the scenario of a total database compromise, the author finds all
hope is already lost at that point.
@ -1067,7 +1063,7 @@ that contains methods on the user object like the following:
\n{1}{Production}
It is, of course, recommended that the application runs in a secure
environment, although definitions of that almost certainly differ depending on
environment although definitions of that almost certainly differ depending on
who you ask. General recommendations would be either to effectively reserve a
machine for a single use case - running this program - so as to dramatically
decrease the potential attack surface of the host, or run the program isolated
@ -1088,7 +1084,7 @@ the database, which would not have to be exposed from the pod and would
therefore only be available over \texttt{localhost}.
It goes without saying that the operator should substitute values of any
default configuration secrets with new ones that were securely generated.
default configuration secrets with the new ones that were securely generated.
\n{2}{Deployment recommendations}
@ -1127,7 +1123,7 @@ user input.
If the application running in a container wants to use the \emph{peer}
authentication method, it is up to the operator to supply the Postgres socket
to the application (e.g.\ as a volume bind mount). This scenario was not
tested, however, and the author is also not entirely certain how \emph{user
tested; however, and the author is also not entirely certain how \emph{user
namespaces} (on GNU/Linux) would influence the process (given that the
\emph{ID}s of a user \textbf{outside} the container are mapped to a range of
\emph{UIDs} \textbf{inside} the container), for which the setup would likely
@ -1169,7 +1165,7 @@ the tooling in the \texttt{go} tool, writing tests is relatively simple. Go
looks for files in the form \texttt{<filename>\_test.go} in the present working
directory but can be instructed to look for test files in packages recursively
found on any path using the ellipsis, like so: \texttt{go test
./path/to/package/\ldots}, which then \emph{runs} all the tests found and
./path/to/package/\ldots}, which then \emph{runs} all the tests found, and
reports some statistics, such as the time it took to run the test or whether it
succeeded or failed. To be precise, the test files also need to contain test
functions, which are functions with the signature \texttt{func TestWhatever(t
@ -1178,7 +1174,7 @@ as the signature. Without it, the function is not considered to be a testing
function despite having the required signature and is therefore \emph{not}
executed during testing.
This test lookup behaviour, however, also has a neat side-effect: all the test
This test lookup behaviour; however, also has a neat side-effect: all the test
files can be kept side-by-side their regular source counterparts, there is no
need to segregate them into a specially blessed \texttt{tests} folder or
similar, which in author's opinion improves readability. As a failsafe, in case
@ -1244,8 +1240,9 @@ The final statements of the described test attempts a user creation call, which
is again checked for both error and \emph{nilability}. The test continues with
more similar checks but it has been cut short for brevity.
A neat thing about error handling in Go is it allows for very easy checking of
all paths, not just the \emph{happy path} where there are no issues.
A neat thing about error handling in Go is that it allows for very easy
checking of all paths, not just the \emph{happy path} where there are no
issues.
\begin{figure}[!h]
\centering