...
 
Commits (10)
Katharina Fey <kookie@spacekookie.de>
Math Jud <jud@wachter-jud.net>
Lux <lux@lux.name> <lux@ontheblueplanet.com>
Lux <lux@lux.name> Lukas Kohler <lukas.kohler@ontheblueplanet.com>
<tristankildaire@gmail.com> <deavmi@users.noreply.github.com>
Jess 3Jane <me@jess.coffee> jess 3jane
......@@ -2,47 +2,37 @@
# qaul.net [![pipeline status](https://git.open-communication.net/qaul/qaul.net/badges/master/pipeline.svg)](https://git.open-communication.net/qaul/qaul.net/commits/master)
**qaul.net** is an Internet independent ad-hoc wireless mesh-network
suite that harnesses the power of everyday devices such as computers and
smartphones to create a **Non-Centralized**, **Mesh Network** on which
users can share files, have voice chats and send each other messages,
however the power of qaul.net allows endless services over the service
API. qaul.net removes the dependence on the centralized services such as
the Internet and cellular networks and creates a network that anyone can
be part of and share freely with no censorship what so ever.
**qaul.net** is an Internet independent ad-hoc wireless mesh-network
suite that harnesses the power of everyday devices such as computers
and smartphones to create a **Non-Centralized**, **Mesh Network** on
which users can share files, have voice chats and send each other
messages, however the power of qaul.net allows endless services over
the service API. qaul.net removes the dependence on the centralized
services such as the Internet and cellular networks and creates a
network that anyone can be part of and share freely with no censorship
what so ever.
## Development status
The project is currently being re-written for a more modular and portable
approach. The new Release will be qaul.net 2.0. Please check
our milestones & issues to get an idea of the development plan and
status.
If you want to get involved, please [get in touch][contributors-guide]!
The project is currently being re-written for a more modular and
portable approach. The new Release will be qaul.net 2.0. Please check
our milestones & issues to get an idea of the development plan and
status. If you want to get involved, please [get in
touch][contributors-guide]!
[contributors-guide]: /contributors/social/_intro.html
For the latest stable release, check the [`release-1.0.0`][release] branch.
For the latest stable release, check the [`release-1.0.0`][release]
branch.
[contributors-guide]: /contributors/social/_intro.html
[release]: https://github.com/qaul/qaul.net/tree/release-1.0.0
qaul.net 2.0 will have the following features:
* File sharing (both private and public)
* Voice calling
* Text messaging (both private and public)
* User discovery (who is in the network)
* Fully encrypted with a decentralized trust model
* Multi network mesh, using several mobile friendly connection modes
* Real time and decentralized mesh communication
* Extendable via service API
## Build Instructions
The project is being re-written in Rust, thus using [cargo][] as a build system.
If you don't have Rust installed, you can get it [here](https://rustup.sh) or via your OS.
The project is being re-written in Rust, thus using [cargo][cargo] as
a build system. If you don't have Rust installed, you can get it
[here](https://rustup.sh) or via your OS.
[cargo]: https://crates.io/
......@@ -54,8 +44,20 @@ Documentation is avaliable [here](https://docs.qaul.net).
## License
qaul.net is free and open source software licensed under the
[GNU Affero General Public License version 3 or later](licenses/gpl-3.0.md).
To see all external code's licenses used in this project please
visit the [`licenses` directory](licenses).
qaul.net is free and open source software licensed under the [GNU
Affero General Public License version 3 or
later](licenses/gpl-3.0.md).
**Additional Permissions:** For Submission to the Apple App Store:
Provided that you are otherwise in compliance with the AGPLv3 for each
covered work you convey (including without limitation making the
Corresponding Source available in compliance with Section 6 of the
AGPLv3), the qaul.net developers also grant you the additional
permission to convey through the Apple App Store non-source executable
versions of the Program as incorporated into each applicable covered
work as Executable Versions only under the Mozilla Public License
version 2.0.
A copy of both the AGPL-3.0 and MPL-2.0 license texts are included in
this repository, along other external licenses for third-party code,
and can be found in the [licenses](licenses) directory.
# qaul.net Contributors' Guide
# qaul.net Contributors' Manual
This guide should always be readable in it's latest version online:
https://docs.qaul.net
This guide is created with the help of the free software
[mdBook](https://rust-lang-nursery.github.io/mdBook/).
It is written by [Markdown](https://www.markdownguide.org/getting-started) files.
Feel free to edit it.
This guide is created with the help of the free software [mdBook]. It
is written in [Markdown] files. Feel free to edit it.
[mdBook]: https://rust-lang-nursery.github.io/mdBook/
[Markdown]: https://www.markdownguide.org/getting-started
## Install mdBook
In order to build this guide you may want to install the free mdBook
In order to build this guide you may want to install the free mdBook
software.
mdBook is written in the programming language Rust. To be able to
install mdBook, please install Rust first. To install Rust please
follow these instructions:
https://rustup.rs/
There are various ways to install mdbook: try getting it from your OS
vendor (Linux distribution, etc) first. If that is not possible, or
your platform does not have a new enough version, you can also easily
build it from source. For this you will need to have Rust installed
(as for the rest of qaul.net).
After installing Rust you can install mdbook as follows:
```
# Install mdBook
......
......@@ -6,6 +6,8 @@
- [Code of Conduct](./social/code-of-conduct.md)
- [Servers & Web Services](./web-services/_intro.md)
- [Technical](./technical/_intro.md)
- [Beta](./technical/beta/_intro.md)
- [Challenges](./technical/beta/challenges.md)
- [Writing Services](./technical/services/_intro.md)
- [Routing Layer](./technical/routing/_intro.md)
- [Routing Table](./technical/routing/routing-table.md)
......
# Introduction
Welcome to the `qaul.net` contributors' guide!
Welcome to the `qaul.net` contributors' manual!
This guide is open and publicly editable. You can find it's sources
in our [gitlab repository].
......
# Beta Report | Braindump
This and the following pages are a brain dump, written on (check
following dates), outlining the current state of affairs, things that
need to be worked on, and things that I (Katharina) don't have the
capacity to work on right now. When outlinging things that are too
complex to solve for me right now, I will try to provide as much
context as possible, both for my future self, as well as other
contributors.
If you see any open questions in this document, and you think you can
help, please send an e-mail to the mailing list, or, if you're shy, to
me personally: kookie@spacekookie.de
## Service API
As of **2020-01-13** the service API is looking pretty good. I've been
hacking on the project full time for ~4 months or so, and there's been
a lot of progress. All basic message functions are implemented, user
creation, authentication, etc. Services can be registered and managed
internally, and can pass mesages through the stack, and receive them
as well. All API endpoints are doing blocking IO, meaning that
callbacks are only done via lambdas.
One paint point here is that we want to move to all async IO, not for
speed but mostly for simplicity in our own scheduling. async-std
implements a good scheduler and it'll be easier for us to use this,
than doing our own stuff with threads. Nora has been working on this
a bunch and the current state (that don't build) are on the `async`
branch on upstream.
## Storage and identity secrecy
An issue that Jess raised a few days ago (as of **2020-10-13**) was
service storage: if we allow people to write services that handle user
data, how do we make sure that they don't just drop that data on the
FS and call it a day? Furthermore, how do we encourage people to
write services that can have their IDs wiped without going all awol,
i.e., we want to encourage ephemeral IDs for activist networks.
A solution to this is that we provide a storage API via libqaul, that
people can use to store arbitrary data that they think is important to
do their whole thing.
One issue that I, and others came up with is where to then store this
data, but also how to avoid sidechannel attacks from a malicious
service that might leak user metadata, i.e. what user uses what
service? This is a bit of an open question because on one hand we
want users to be able to announce services, but it should also be
possible to run hidden services, that might not be legal to run.
Furthermore, how do we design an abstraction over the secure store
provided by alexandria (also wip) that doesn't fall victim to a
padding-oracle-like attack, i.e. a service that can send queries for
various users and services and looking at the failure responses to
figure out what user is running what services. There's another
layer to this, which is that we do expose a list of local IDs via a
user endpoint so that the frontend can render a list of users to login
as, for someone to just select. This obviously means that any code
running on the user's device will have access to the list of users on
the device.
One possible mitigating factor here would be to have users marked as
"secret", where even libqaul itself doesn't know if it owns data for a
user. A user would provide a secret, and their own key, similar to
how the detached identities hash challenge works (outlined later?), to
decrypt a user manifest and the load all the state from alexandria.
This would mean that a user is unknown to peers outside of the current
user session, or by dumping the libqaul memory space from a
priviledged user (but honestly, if an adversary owns your device
there's very little you can do - we should look into if mbedtls
supports linux secmem extentions!)
As for hidder services for a user, we can use the same mechanism as
the hidden user directory, except that we generate a secret for a
service which is required when performing service lookup queries.
When a user signs in, we can load the hidden service secrets from the
user manifest, then unlock the service data, which is ambiguated at
rest. If a malicious service tries to check for a service on a user
by trying to load certain files from storage, it will require the
service auth token which was only handed to the hidden service. The
initialisation of the hidden service then follows another challenge
response mechanism, similar to how we can load a hidden user: the
hidden service generates a token, the user uses a trusted app to auth
that token, then the serice secret is passed to the hidden service.
Again, if the attacker can dump memory... etc etc.
I think these threat models are realistic, and my solutions offer a
viable protection mechanism against them. There's some open questions,
but this should be enough te implement the required endpoints in the
service API now. I would suggest either adding a storage endpoint, or
expanding the service endpoint if there aren't too many functions.
## Malicious daemon
Not something that I want to write as much about here because the
problem has way more factors and this is not a part of security
analysis that I know much about (see previous section for application
and protocol security): system integration and malicious daemons.
Say a user installs a malicious instance of libqaul, and it registers
itself with dbus, intents, etc and now other applications, possibly
our qaul.net app itself, will start talking to it. Is there anything
we can do? Qaul.net, the app, could pin it's daemon, but that would
be annoying, especially because it could deter any app from connecting
to any daemon, rendering the whole point of the API useless.
Shipping keys doesn't work (lol, why do people keep trying this?),
maybe we could get people to checksum their binaries? But also hard.
Anyway, I'll move on because there's more to cover.
## Ratman, routing and async (again)
The current state in ratman is a mess. Messages can be routed, but
floods don't work because they don't get deduplicated. To do this
well, we need to finish the journal, which should index frames by ID,
and then refuse to broadcast when it has already send a specific frame
ID. Also, there's a lot of mising logic to rebuild the sliced
messages, and also I had a conversation at 36c3 about doing the
slicing in a more clever way. TODO: message Jeff.
When it comes to asyncing, there's a lot of work to do: ratman itself
needs to get async internals so that we can actually call the netmod
interface that now exists, but also we need to make sure that we can
wrap blocking calls properly? Like, how do we call into native drivers
that can't do async in Rust? I have some ideas about how to build the
interfaces up on the async branch, but this all needs integration and
I'm drawing a blank how this will actually look in C++, so maybe it's
time to actually build the Android abstractions? I don't know.
After Ratman has an async API towards libqaul we need to async the
core of that, and also make sure that we give Ratman a similar
abstraction for the native code because let's remember that
initialisation of a stack happens from the bottom up and all these
APIs are gonna have to be wrapped for C++!
Hmm... I might have missed some things, but that's been making me
anxious for the last 2 weeks or so. Please talk to me about these
things if you have ideas, thoughts or suggestions.
Check the "Challenges" section following this, for some ideas that you
(yes you!) could get started with, if you wanted to help out with
developing qaul.net.
# Challenges
You wanna help? You're so cool ❤ Here's a list of things that need
doing, similar to how an issue tracker would outline them. We'll try
to keep this list up-to-date, and also always feel free to e-mail the
"community" mailing list for feedback or ask on IRC!
## Filesharing service
That sounds hard, but it's not that hard! There's no abstractions for
you to introduce because libqaul provides all of them for you! Now, we
might end up removing this abstraction from libqaul again, and moving
it to the service entirely, but that can be done later.
There's "File", "FileMeta", and "FileFilter". We need to provide
people with an API with which they can announce, send and query for
files. The service API itself needs to take a file, serialise it with
"conjoiner_engine", the same serialiser user all over libqaul and the
messaging service (just check there how to use it), and send them out
as messages to either the entire network (as a "fileannounce type"),
or just to one person.
When the service get's a "FileRequest" (TODO: add that type to "FileMeta", it needs to load the file from
disk, and then send it.
If you have questions, don't hesitate to ask!
## UDP driver testing
There's netmod-udp in the qaul.net tree, and while it's mostly (?)
done, it could use some testing. Best to just ping spacekookie or pbb
on IRC or the mailing list for this, as it's a bit more vague.
......@@ -10,7 +10,7 @@ to get you up and running.
You will need the following things properly installed on your computer.
* [Git](https://git-scm.com/)
* [Node.js](https://nodejs.org/) *(you need node version <10 due dependencies..., 2018/05/07)*
* [Node.js](https://nodejs.org/)
* [Yarn](https://yarnpkg.com/)
* [Ember CLI](https://ember-cli.com/)
* [Google Chrome](https://google.com/chrome/)
......
/* eslint-env node */
'use strict';
module.exports = function(deployTarget) {
let ENV = {
build: {},
// include other plugin configuration that applies to all deploy targets here
gzip: {}
};
ENV.build.outputPath = process.env.DEPLOY_PATH || 'deploy';
// ENV.gzip.filePattern = '\*\*/\*.{js,css,json,ico,html,svg,otf,eot,ttf,woff,woff2}';
ENV.gzip.keep = 'true';
if (deployTarget === 'development') {
ENV.build.environment = 'development';
// configure other plugins for development deploy target here
}
if (deployTarget === 'staging') {
ENV.build.environment = 'production';
// configure other plugins for staging deploy target here
}
if (deployTarget === 'production') {
ENV.build.environment = 'production';
// configure other plugins for production deploy target here
}
// Note: if you need to build some configuration asynchronously, you can return
// a promise that resolves with the ENV object instead of returning the
// ENV object synchronously.
return ENV;
};