tex: add batch 1
This commit is contained in:
parent
46008320d5
commit
ef8673e9a2
BIN
graphics/drone-median-build.png
Normal file
BIN
graphics/drone-median-build.png
Normal file
Binary file not shown.
After Width: | Height: | Size: 102 KiB |
@ -8,14 +8,17 @@
|
|||||||
SHA & Secure Hash Algorithm \\
|
SHA & Secure Hash Algorithm \\
|
||||||
AES & Advanced Encryption Standard \\
|
AES & Advanced Encryption Standard \\
|
||||||
|
|
||||||
ID & identity \\
|
ID & Identity \\
|
||||||
PID & process ID \\
|
PID & Process ID \\
|
||||||
Cgroup & control group \\
|
Cgroup & Control group \\
|
||||||
|
|
||||||
TLS & Transport Layer Security \\
|
TLS & Transport Layer Security \\
|
||||||
SSH & Secure Shell \\
|
SSH & Secure Shell \\
|
||||||
|
GPG & GNU Privacy Guard \\
|
||||||
|
GNU & GNU's Not Unix! \\
|
||||||
CSS & Cascading Style Sheets \\
|
CSS & Cascading Style Sheets \\
|
||||||
API & Application Programming Interface \\
|
API & Application Programming Interface \\
|
||||||
|
SCM & Source Code Management \\
|
||||||
HIBP & Have I Been Pwned \\
|
HIBP & Have I Been Pwned \\
|
||||||
|
|
||||||
TOML & Tom's Obvious Minimal Language \\
|
TOML & Tom's Obvious Minimal Language \\
|
||||||
@ -25,6 +28,8 @@ INI & Initialization file \\
|
|||||||
|
|
||||||
OWASP & Open Web Application Security Project \\
|
OWASP & Open Web Application Security Project \\
|
||||||
NIST & National Institute of Standards and Technology \\
|
NIST & National Institute of Standards and Technology \\
|
||||||
|
|
||||||
|
SEO & Search-Engine Optimisation \\
|
||||||
\end{tabular}
|
\end{tabular}
|
||||||
|
|
||||||
% =========================================================================== %
|
% =========================================================================== %
|
||||||
|
@ -148,4 +148,13 @@
|
|||||||
note={{Available from: \url{https://man7.org/linux/man-pages/man7/namespaces.7.html}. [viewed 2023-05-17]}}
|
note={{Available from: \url{https://man7.org/linux/man-pages/man7/namespaces.7.html}. [viewed 2023-05-17]}}
|
||||||
}
|
}
|
||||||
|
|
||||||
|
@misc{agwagitssh,
|
||||||
|
howpublished = {[online]},
|
||||||
|
title = {It's Now Possible TO Sign Arbitrary Data With Your SSH Keys},
|
||||||
|
author = {Andrew Ayer},
|
||||||
|
year = 2021,
|
||||||
|
month = nov,
|
||||||
|
note={{Available from: \url{https://www.agwa.name/blog/post/ssh_signatures}. [viewed 2023-05-17]}}
|
||||||
|
}
|
||||||
|
|
||||||
% =========================================================================== %
|
% =========================================================================== %
|
||||||
|
292
tex/text.tex
292
tex/text.tex
@ -31,13 +31,13 @@ Linux kernel~\cite{linux}.
|
|||||||
|
|
||||||
\n{2}{GNU/Linux}
|
\n{2}{GNU/Linux}
|
||||||
|
|
||||||
When talking about an operating system, the term ``GNU/Linux'' as defined by
|
As far as a Linux-based operating system is concerned, the term ``GNU/Linux''
|
||||||
the Free Software Foundation~\cite{fsfgnulinux} is used. While it is longer and
|
as defined by the Free Software Foundation~\cite{fsfgnulinux} is used. While it
|
||||||
arguably a little bit cumbersome, the author aligns with the opinion that this
|
is longer and arguably a little bit cumbersome, the author aligns with the
|
||||||
term more correctly describes its actual target. Being aware there are many
|
opinion that this term more correctly describes its actual target. Being aware
|
||||||
people that conflate the complete operating system with its (be it core)
|
there are many people that conflate the complete operating system with its (be
|
||||||
component, the kernel, the author is taking care to distinguish the two,
|
it core) component, the kernel, the author is taking care to distinguish the
|
||||||
although writing from experience, colloquially, this probably brings more
|
two, although writing from experience, colloquially, this probably brings more
|
||||||
confusion and a lengthy explanation is usually required.
|
confusion and a lengthy explanation is usually required.
|
||||||
|
|
||||||
|
|
||||||
@ -71,7 +71,7 @@ Pre-requisites necessary for following up.
|
|||||||
Explanation. What are hash functions
|
Explanation. What are hash functions
|
||||||
|
|
||||||
\n{3}{Uses and \textit{mis}uses}
|
\n{3}{Uses and \textit{mis}uses}
|
||||||
The good the bad and the ugly of hash usage (including or in some cases
|
The good, the bad and the ugly of hash usage (including or in some cases
|
||||||
excluding salting, weak hashes, split hashes (Microsoft)).
|
excluding salting, weak hashes, split hashes (Microsoft)).
|
||||||
|
|
||||||
\n{3}{Threats to hashes}
|
\n{3}{Threats to hashes}
|
||||||
@ -93,7 +93,7 @@ Generally.
|
|||||||
\n{3}{Arbitrary length requirements (min/max)}
|
\n{3}{Arbitrary length requirements (min/max)}
|
||||||
\n{3}{Arbitrary complexity requirements}
|
\n{3}{Arbitrary complexity requirements}
|
||||||
\n{3}{Restricting special characters}
|
\n{3}{Restricting special characters}
|
||||||
Service providers have too often been found to forbid the use of so called
|
Service providers have too often been found forbidding the use of so called
|
||||||
\textit{special characters} in passwords for as long as passwords have been
|
\textit{special characters} in passwords for as long as passwords have been
|
||||||
used to protect privileged access. Ways of achieving the same may vary but the
|
used to protect privileged access. Ways of achieving the same may vary but the
|
||||||
intent stays the same: prevent users from inputting characters into the system,
|
intent stays the same: prevent users from inputting characters into the system,
|
||||||
@ -105,12 +105,14 @@ Entropy, dictionaries, multiple factors.
|
|||||||
|
|
||||||
|
|
||||||
\n{1}{Web security}\label{sec:websecurity}
|
\n{1}{Web security}\label{sec:websecurity}
|
||||||
The internet being the vast space of intertwined concepts and ideas, is a
|
|
||||||
|
The internet, being the vast space of intertwined concepts and ideas, is a
|
||||||
superset of the Web, which is the part of the internet zoomed in on in this
|
superset of the Web, which is the part of the internet zoomed in on in this
|
||||||
section.
|
section.
|
||||||
|
|
||||||
\n{2}{Browsers}\label{sec:browsers}
|
\n{2}{Browsers}\label{sec:browsers}
|
||||||
What they are, what do they do, how do they relate into the security aspect
|
|
||||||
|
What they are, what do they do, how they relate to the security aspect
|
||||||
(privileged process running untrusted code on user's computer), history,
|
(privileged process running untrusted code on user's computer), history,
|
||||||
present, security focus of the dev teams, user facing signalling (padlock
|
present, security focus of the dev teams, user facing signalling (padlock
|
||||||
colours, scary warnings).
|
colours, scary warnings).
|
||||||
@ -118,6 +120,7 @@ colours, scary warnings).
|
|||||||
TODO: describe how browsers find out where the web page lives, get a webpage,
|
TODO: describe how browsers find out where the web page lives, get a webpage,
|
||||||
parse it, parse stylesheets, run scripts, apply SAMEORIGIN restrictions etc.
|
parse it, parse stylesheets, run scripts, apply SAMEORIGIN restrictions etc.
|
||||||
|
|
||||||
|
|
||||||
\n{2}{Cross-site scripting}\label{sec:xss}
|
\n{2}{Cross-site scripting}\label{sec:xss}
|
||||||
|
|
||||||
\n{2}{Content Security Policy}\label{sec:csp}
|
\n{2}{Content Security Policy}\label{sec:csp}
|
||||||
@ -173,12 +176,15 @@ following are certain to make the count:
|
|||||||
\textbf{Disclaimer:} the author is not affiliated in any way with any of the
|
\textbf{Disclaimer:} the author is not affiliated in any way with any of the
|
||||||
projects described on this page.
|
projects described on this page.
|
||||||
|
|
||||||
The \textit{Password Compromise Monitoring Tool} (\texttt{pcmt}) program has been
|
The \textit{Password Compromise Monitoring Tool} (\texttt{pcmt}) program has
|
||||||
developed using and utilising a great deal of open-source software in the
|
been developed using and utilising a great deal of free (as in Freedom) and
|
||||||
process, either directly or as an outstanding work tool, and the author would
|
open-source software in the process, either directly or as an outstanding work
|
||||||
like to take this opportunity to recognise that fact.
|
tool, and the author would like to take this opportunity to recognise that
|
||||||
|
fact.
|
||||||
|
|
||||||
|
In particular, the author acknowledges that this work would not be the same
|
||||||
|
without:
|
||||||
|
|
||||||
In particular, this work would not be the same without:
|
|
||||||
\begin{itemize}
|
\begin{itemize}
|
||||||
\item vim (\url{https://www.vim.org/})
|
\item vim (\url{https://www.vim.org/})
|
||||||
\item Arch Linux (\url{https://archlinux.org/})
|
\item Arch Linux (\url{https://archlinux.org/})
|
||||||
@ -192,13 +198,159 @@ In particular, this work would not be the same without:
|
|||||||
|
|
||||||
All of the code written has been typed into VIM (\texttt{9.0}), the shell used
|
All of the code written has been typed into VIM (\texttt{9.0}), the shell used
|
||||||
to run the commands was ZSH, both running in the author's terminal emulator of
|
to run the commands was ZSH, both running in the author's terminal emulator of
|
||||||
choice - \texttt{kitty} on a (at the time of writing) 8 month installation of
|
choice - \texttt{kitty} on a \raisebox{.8ex}{\texttildelow}8 month (at the time
|
||||||
\textit{Arch Linux (by the way)} using a \texttt{6.3.1-wanderer-zfs-xanmod1}
|
of writing) installation of \textit{Arch Linux (by the way)} using a
|
||||||
variant of the Linux kernel.
|
\texttt{6.3.1-wanderer-zfs-xanmod1} variant of the Linux kernel.
|
||||||
|
|
||||||
|
|
||||||
\n{1}{Development}
|
\n{1}{Development}
|
||||||
|
|
||||||
|
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
|
||||||
|
message \emph{hygiene}, i.e.\ striving for meaningful and well-formatted commit
|
||||||
|
messages. The name of the default branch is \texttt{development}, since that is
|
||||||
|
what the author likes to choose for new projects that are not yet stable (it is
|
||||||
|
in fact the default in author's \texttt{.gitconfig}).
|
||||||
|
|
||||||
|
|
||||||
|
\n{2}{Commit signing}
|
||||||
|
|
||||||
|
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
|
||||||
|
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
|
||||||
|
author has, of course, not reused the same key pair that is used to connect to
|
||||||
|
machines for signing commits. A different, \texttt{Ed25519} elliptic curve key
|
||||||
|
pair has been used specifically for signing. A public component of this key is
|
||||||
|
enclosed to this thesis as an attachment for future reference.
|
||||||
|
|
||||||
|
The validity of a signature on a particular commit can be viewed with git using
|
||||||
|
the following commands (the \% sign denotes the shell prompt):
|
||||||
|
|
||||||
|
\begin{figure}[h]
|
||||||
|
\centering
|
||||||
|
\begin{varwidth}{\linewidth}
|
||||||
|
\begin{verbatim}
|
||||||
|
% cd <cloned project dir>
|
||||||
|
% git show --show-signature <commit>
|
||||||
|
% # alternatively:
|
||||||
|
% git verify-commit <commit>
|
||||||
|
\end{verbatim}
|
||||||
|
\end{varwidth}
|
||||||
|
\caption{Verifying signature of a git commit}
|
||||||
|
\label{fig:gitverif}
|
||||||
|
\end{figure}
|
||||||
|
|
||||||
|
There is one caveat to this though, git first needs some additional
|
||||||
|
configuration for the code in Figure~\ref{fig:gitverif} to work as one would
|
||||||
|
expect. Namely that the public key used to verify the signature needs to be
|
||||||
|
stored in git's ``allowed signers file'', then git needs to be told where that
|
||||||
|
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:
|
||||||
|
|
||||||
|
\begin{figure}[h]
|
||||||
|
\centering
|
||||||
|
\begin{varwidth}{\linewidth}
|
||||||
|
\scriptsize
|
||||||
|
\begin{verbatim}
|
||||||
|
% # set the signature format for the local repository.
|
||||||
|
% git config --local gpg.format ssh
|
||||||
|
% # save the public key.
|
||||||
|
% cat >./tmp/.allowed_signers \
|
||||||
|
<<<'leo ssh-ed25519 AAAAC3NzaC1lZDI1NTE5AAAAIKwshTdBgLzwY4d8N7VainZCngH88OwvPGhZ6bm87rBO'
|
||||||
|
% # set the allowed signers file path for the local repository.
|
||||||
|
% git config --local gpg.ssh.allowedsignersfile=./tmp/.allowed_signers
|
||||||
|
\end{verbatim}
|
||||||
|
\end{varwidth}
|
||||||
|
\caption{Prepare allowed signers file and signature format for git}
|
||||||
|
\label{fig:gitsshprep}
|
||||||
|
\end{figure}
|
||||||
|
|
||||||
|
After the code in Figure~\ref{fig:gitsshprep} is run, everything from the
|
||||||
|
Figure~\ref{fig:gitverif} should remain applicable for the lifetime of the
|
||||||
|
repository or until git changes implementation of signature verification.
|
||||||
|
|
||||||
|
For future reference, git has been used in the version \texttt{git version
|
||||||
|
2.40.1}.
|
||||||
|
|
||||||
|
|
||||||
|
\n{2}{Continuous Integration}
|
||||||
|
|
||||||
|
To increase both the author's and public confidence in the atomic changes made
|
||||||
|
over time, it was attempted to thoroughly \emph{integrate} them using a
|
||||||
|
continuous integration (CI) service that was plugged into the main source code
|
||||||
|
repository since the early stages of development. This, of course, was again
|
||||||
|
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
|
||||||
|
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
|
||||||
|
it to be cloned only from \emph{origin} only at the start of the pipeline and
|
||||||
|
then shared for all of the following steps, saving bandwidth, time and disk
|
||||||
|
writes.
|
||||||
|
|
||||||
|
The entire configuration used to run the pipelines can be found in a file named
|
||||||
|
\texttt{.drone.yml} at the root of the main source code repository. The
|
||||||
|
workflow consists of three pipelines, which are run in parallel. Two main
|
||||||
|
pipelines are defined to build the 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 were 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 was defined to build a popular static analysis tool called
|
||||||
|
\texttt{golangci-lint} - which is sort of a meta-linter, bundling a staggering
|
||||||
|
amount of linters (linter is a tool that performs static code analysis and can
|
||||||
|
raise awareness of programming errors, flag potentially buggy code constructs,
|
||||||
|
or \emph{mere} stylistic errors) - from sources and then perform the analysis
|
||||||
|
of project's codebase using the freshly built binary. If the result of this
|
||||||
|
step is successful, a handful of code analysis services get pinged in the next
|
||||||
|
steps to take notice of the changes to project's source code and update their
|
||||||
|
metrics, details can be found in the main Drone configuration file
|
||||||
|
\texttt{.drone.yml} and the configuration of \texttt{golangci-lint} can be
|
||||||
|
found in the root of the repository in the file named \texttt{.golangci.yml}.
|
||||||
|
The median build time as of writing was 1 minute, which includes running all
|
||||||
|
three pipelines, and that is acceptable.
|
||||||
|
|
||||||
|
\obr{Drone CI median
|
||||||
|
build}{fig:drone-median-build}{.77}{graphics/drone-median-build}
|
||||||
|
|
||||||
|
|
||||||
|
\n{2}{Source code repositories}\label{sec:repos}
|
||||||
|
|
||||||
|
All of the pertaining source code was published in repositories on a publicly
|
||||||
|
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,
|
||||||
|
acting on impulse or under public pressure (potentially at least temporarily
|
||||||
|
disrupting their user's operations), thus beholding their user to their lengthy
|
||||||
|
\emph{terms of service} that \emph{can change at any time}. Granted,
|
||||||
|
decentralisation can take a toll on discoverability of the project, but that is
|
||||||
|
not of concern here.
|
||||||
|
|
||||||
|
The git repository containing source code of the \texttt{pcmt} project:\\
|
||||||
|
\url{https://git.dotya.ml/mirre-mt/pcmt.git}.
|
||||||
|
|
||||||
|
The git repository hosting the \texttt{pcmt} configuration schema:\\
|
||||||
|
\url{https://git.dotya.ml/mirre-mt/pcmt-config-schema.git}.
|
||||||
|
|
||||||
|
The repository containing the \LaTeX{} source code of this thesis:\\
|
||||||
|
\url{https://git.dotya.ml/mirre-mt/masters-thesis.git}.
|
||||||
|
|
||||||
|
|
||||||
\n{2}{Toolchain}
|
\n{2}{Toolchain}
|
||||||
|
|
||||||
Throughout the creation of this work, the \emph{current} version of the Go
|
Throughout the creation of this work, the \emph{current} version of the Go
|
||||||
@ -234,7 +386,8 @@ errors are values.
|
|||||||
The appeal for the author comes from a number of language features, such as
|
The appeal for the author comes from a number of language features, such as
|
||||||
built-in support for concurrency, testing, sane \emph{zero} values, lack of
|
built-in support for concurrency, testing, sane \emph{zero} values, lack of
|
||||||
pointer arithmetic, inheritance and implicit type conversions, easy-to-read
|
pointer arithmetic, inheritance and implicit type conversions, easy-to-read
|
||||||
syntax, producing a statically linked binary by default, etc.
|
syntax, producing a statically linked binary by default, etc., on top of that,
|
||||||
|
the language has got a cute mascot.
|
||||||
|
|
||||||
Due to the foresight of the authors of the Go Authors regarding \emph{the
|
Due to the foresight of the authors of the Go Authors regarding \emph{the
|
||||||
formatting question} (i.e.\ where to put the braces, tabs vs.\ spaces, etc.),
|
formatting question} (i.e.\ where to put the braces, tabs vs.\ spaces, etc.),
|
||||||
@ -277,12 +430,79 @@ usage of custom types (that are, of course merely combinations of the primitive
|
|||||||
types that the language provides, such as \emph{Bool}, \emph{Natural} or
|
types that the language provides, such as \emph{Bool}, \emph{Natural} or
|
||||||
\emph{List}, to name just a few), so it was not exceedingly hard to start
|
\emph{List}, to name just a few), so it was not exceedingly hard to start
|
||||||
designing a custom configuration \emph{schema} for the program.
|
designing a custom configuration \emph{schema} for the program.
|
||||||
|
|
||||||
Dhall not being a Turing-complete language also guarantees that evaluation
|
Dhall not being a Turing-complete language also guarantees that evaluation
|
||||||
\emph{always} terminates eventually, which is a good attribute to possess as a
|
\emph{always} terminates eventually, which is a good attribute to possess as a
|
||||||
configuration language.
|
configuration language.
|
||||||
|
|
||||||
|
|
||||||
|
\n{3}{Schema}
|
||||||
|
|
||||||
|
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).
|
||||||
|
|
||||||
|
\begin{figure}[h]
|
||||||
|
\begin{varwidth}
|
||||||
|
\scriptsize
|
||||||
|
\begin{verbatim}
|
||||||
|
let Schema =
|
||||||
|
{ Type =
|
||||||
|
{ Host : Text
|
||||||
|
, Port : Natural
|
||||||
|
, HTTP :
|
||||||
|
{ Domain : Text
|
||||||
|
, Secure : Bool
|
||||||
|
, AutoTLS : Bool
|
||||||
|
, TLSKeyPath : Text
|
||||||
|
, TLSCertKeyPath : Text
|
||||||
|
, HSTSMaxAge : Natural
|
||||||
|
, ContentSecurityPolicy : Text
|
||||||
|
, RateLimit : Natural
|
||||||
|
, Gzip : Natural
|
||||||
|
, Timeout : Natural
|
||||||
|
}
|
||||||
|
, Mailer :
|
||||||
|
{ Enabled : Bool
|
||||||
|
, Protocol : Text
|
||||||
|
, SMTPAddr : Text
|
||||||
|
, SMTPPort : Natural
|
||||||
|
, ForceTrustServerCert : Bool
|
||||||
|
, EnableHELO : Bool
|
||||||
|
, HELOHostname : Text
|
||||||
|
, Auth : Text
|
||||||
|
, From : Text
|
||||||
|
, User : Text
|
||||||
|
, Password : Text
|
||||||
|
, SubjectPrefix : Text
|
||||||
|
, SendPlainText : Bool
|
||||||
|
}
|
||||||
|
, LiveMode : Bool
|
||||||
|
, DevelMode : Bool
|
||||||
|
, AppPath : Text
|
||||||
|
, Session :
|
||||||
|
{ CookieName : Text
|
||||||
|
, CookieAuthSecret : Text
|
||||||
|
, CookieEncrSecret : Text
|
||||||
|
, MaxAge : Natural
|
||||||
|
}
|
||||||
|
, Logger : { JSON : Bool, Fmt : Optional Text }
|
||||||
|
, Init : { CreateAdmin : Bool, AdminPassword : Text }
|
||||||
|
, Registration : { Allowed : Bool }
|
||||||
|
}
|
||||||
|
, default = {=}
|
||||||
|
}
|
||||||
|
|
||||||
|
in Schema
|
||||||
|
\end{verbatim}
|
||||||
|
\end{varwidth}
|
||||||
|
\caption{Dhall configuration schema version 0.0.1-rc.1}
|
||||||
|
\label{fig:dhallschema}
|
||||||
|
\end{figure}
|
||||||
|
|
||||||
|
|
||||||
\n{3}{Safety considerations}
|
\n{3}{Safety considerations}
|
||||||
|
|
||||||
Having a programmable configuration language that understands functions and
|
Having a programmable configuration language that understands functions and
|
||||||
allows importing not only arbitrary text from random internet URLs, but also
|
allows importing not only arbitrary text from random internet URLs, but also
|
||||||
importing and \emph{evaluating} (i.e.\ running) potentially untrusted code, it
|
importing and \emph{evaluating} (i.e.\ running) potentially untrusted code, it
|
||||||
@ -298,15 +518,16 @@ shortcomings of Dhall, namely long start-up with \emph{cold cache}, which can
|
|||||||
generally be observed in the scenario of running the program in a
|
generally be observed in the scenario of running the program in a
|
||||||
\emph{container}.
|
\emph{container}.
|
||||||
|
|
||||||
The way that Dhall works is it resolves every expression down to a combination
|
If we want to describe the way Dhall works when performing an evaluation, it
|
||||||
of its most basic types (eliminating all abstraction and indirection) in the
|
resolves every expression down to a combination of its most basic types
|
||||||
process called \textbf{normalisation}~\cite{dhallnorm} and then saves this
|
(eliminating all abstraction and indirection) in the process called
|
||||||
result in the hosts cache. The \texttt{dhall-haskell} binary attempts to
|
\textbf{normalisation}~\cite{dhallnorm} and then saves this result in the hosts
|
||||||
resolve the variable \texttt{XDG\_CACHE\_HOME} (have a look at \emph{XDG Base
|
cache. The \texttt{dhall-haskell} binary attempts to resolve the variable
|
||||||
Directory Spec}~\cite{xdgbasedirspec} for details) to decide \emph{where} the
|
\texttt{XDG\_CACHE\_HOME} (have a look at \emph{XDG Base Directory
|
||||||
results of the normalisation will be written for repeated use. Do note that
|
Spec}~\cite{xdgbasedirspec} for details) to decide \emph{where} the results of
|
||||||
this behaviour has been observed on a GNU/Linux host and the author has not
|
the normalisation will be written for repeated use. Do note that this
|
||||||
verified this behaviour on a non-GNU/Linux host.
|
behaviour has been observed on a GNU/Linux host and the author has not verified
|
||||||
|
this behaviour on a non-GNU/Linux host.
|
||||||
|
|
||||||
If normalisation is performed inside an ephemeral container (as opposed to, for
|
If normalisation is performed inside an ephemeral container (as opposed to, for
|
||||||
instance, an interactive desktop session), the results effectively get lost on
|
instance, an interactive desktop session), the results effectively get lost on
|
||||||
@ -406,11 +627,6 @@ access to the database.
|
|||||||
\n{1}{Implementation}
|
\n{1}{Implementation}
|
||||||
|
|
||||||
\n{2}{Compromise checking}
|
\n{2}{Compromise checking}
|
||||||
Periodicity, alerting mechanisms (email, Telegram..)
|
|
||||||
\\
|
|
||||||
The above will be scrapped as there will be no way for the application to
|
|
||||||
access the user data since it will be encrypted by a key, passphrase to which
|
|
||||||
only the user knows.
|
|
||||||
|
|
||||||
\n{3}{Have I Been Pwned? Integration}
|
\n{3}{Have I Been Pwned? Integration}
|
||||||
TODO
|
TODO
|
||||||
@ -546,9 +762,9 @@ namespaces} (on GNU/Linux) would influence the process (given that the
|
|||||||
need to account.
|
need to account.
|
||||||
|
|
||||||
Equally, if the application is running inside the container, the operator needs
|
Equally, if the application is running inside the container, the operator needs
|
||||||
to make sure the database is either running in a network that is also directly
|
to make sure that the database is either running in a network that is also
|
||||||
attached to the container or that there is a mechanism in place that routes the
|
directly attached to the container or that there is a mechanism in place that
|
||||||
requests for the database hostname to the destination.
|
routes the requests for the database hostname to the destination.
|
||||||
|
|
||||||
One such mechanism is container name based routing inside \emph{pods}
|
One such mechanism is container name based routing inside \emph{pods}
|
||||||
(Podman/Kubernetes), where the resolution of container names is the
|
(Podman/Kubernetes), where the resolution of container names is the
|
||||||
|
Reference in New Issue
Block a user