Skip to content
Snippets Groups Projects

Compare revisions

Changes are shown as if the source revision was being merged into the target revision. Learn more about comparing revisions.

Source

Select target project
No results found
Select Git revision
  • master
  • setup-reviewapp
2 results

Target

Select target project
  • kwadronaut/leap_se
  • LucasLarson/leap_se
  • jubobot/leap_se
  • wxl/leap_se
  • meskio/leap_se
  • whilelm/leap_se
  • vdegou/leap_se
  • southerntofu/leap_se
8 results
Select Git revision
  • master
  • patch-1
  • setup-reviewapp
3 results
Show changes

Commits on Source 44

Showing
with 569 additions and 263 deletions
---
variables:
OPENSHIFT_SERVER: hexacab.org:8443
OPENSHIFT_DOMAIN: apps.hexacab.org
PROJECT_NAME: leapse
# Configure this variable in Secure Variables:
# OPENSHIFT_TOKEN: my.openshift.token
stages:
- review
- production
- cleanup
.deploy: &deploy
image: ayufan/openshift-cli
before_script:
- oc login "${OPENSHIFT_SERVER}" --token="${OPENSHIFT_TOKEN}"
- oc project "${PROJECT_NAME}-${CI_PROJECT_ID}" 2> /dev/null || oc new-project "${PROJECT_NAME}-${CI_PROJECT_ID}"
script:
- "oc get services ${APP} 2> /dev/null || oc new-app ${CI_REPOSITORY_URL}#${CI_COMMIT_REF_NAME} --name=${APP} --strategy=docker && sleep 3 && oc logs -f bc/${APP}"
- "oc status -v"
- "oc expose dc ${APP} --port=8080 && oc expose service ${APP} --port=8080 --hostname=${PROJECT_NAME}-${CI_ENVIRONMENT_SLUG}.${OPENSHIFT_DOMAIN}"
review:
<<: *deploy
stage: review
variables:
APP: review-$CI_COMMIT_REF_NAME
APP_HOST: $PROJECT_NAME-$CI_ENVIRONMENT_SLUG.$OPENSHIFT_DOMAIN
environment:
name: review/$CI_COMMIT_REF_NAME
url: http://$PROJECT_NAME-$CI_ENVIRONMENT_SLUG.$OPENSHIFT_DOMAIN
on_stop: stop-review
only:
- branches
except:
- master
stop-review:
<<: *deploy
stage: cleanup
script:
- oc delete all -l "app=$APP"
when: manual
variables:
APP: review-$CI_COMMIT_REF_NAME
GIT_STRATEGY: none
environment:
name: review/$CI_COMMIT_REF_NAME
action: stop
only:
- branches
except:
- master
production:
image: 0xacab.org:4567/leap/docker/ruby:stretch_amd64
......@@ -60,7 +8,7 @@ production:
environment:
name: production
only:
- master
- master@leap/leap_se
before_script:
# install ssh-agent
- 'which ssh-agent || ( apt-get update -y && apt-get install openssh-client -y )'
......
......@@ -4,4 +4,4 @@
%a{:rel => "license", :href => "https://creativecommons.org/licenses/by-sa/3.0/"}<
%img{:alt => "Creative Commons License", :style => "border-width:0; vertical-align: middle", :src => "/img/by-sa-3.0-80x15.png"}
&nbsp;
<span>(c) 2012-2017 LEAP Encryption Access Project</span>
<span>(c) 2012-2020 LEAP Encryption Access Project</span>
.masthead-inner
.container
.row
-# if has_navigation?
.col-sm-3.col-md-2
.col-sm-9.col-md-10
%header
%picture
%source{:media => "(min-width: 35.5em)", :srcset => "/img/leap180.png"}
%img{:alt => "LEAP logo", :src => "/img/leap128.png"}
%h1 LEAP Encryption Access Project
%ul.list-unstyled#top-menu
%nav.nav-menu{:role => "navigation"}
- top_navigation_items(include_home:true) do |item|
%li{:class => [item[:class], 'tab'].join(' ')}
%a{:href => item[:href], :class => [item[:class], 'tab'].join(' ')}= item[:label]
.col-sm-12.logo
%h1 LEAP Encryption Access Project
%ul.list-unstyled#top-menu
- top_navigation_items(include_home:true) do |item|
%li{:class => [item[:class], 'tab'].join(' ')}
%a{:href => item[:href], :class => [item[:class], 'tab'].join(' ')}= item[:label]
%a.nav-item{:href => item[:href], :class => item[:class]}= item[:label]
......@@ -9,8 +9,6 @@
%link(rel="stylesheet" href="/assets/font-awesome/css/font-awesome.min.css")
= html_head_base
%body
#wrap
#masthead
= render 'layouts/masthead'
#main.container
.row
......@@ -32,7 +30,6 @@
= yield :title
.content-box
= yield :content
#footer
= render 'layouts/footer'
#background
......@@ -6,6 +6,9 @@ about-us
# people
contact
news
2020
2019
2018
2017
2016
2015
......
@title = 'Maintenance release: Bionic packages and long term evolution'
@author = 'kwadronaut'
@posted_at = '2018-07-26'
@more = true
@preview_image = '/img/pages/bionic.png'
Update from the coagulated brains in LEAP
----------------------------------------------------------------------------------------------------
Mid july we released packages as a maintanance release with support for Ubuntu 18.04 (Bionic). For install instructions check out https://dl.bitmask.net/linux/
The bundles however have not been updated, our plan is to deprecate them and migrate to [Snap-packages](https://en.wikipedia.org/wiki/Snappy_\(package_manager\) ), which will take some time. As usual bug reports and feedback is very welcome.
If you want to follow developments or experiment with those Snap packages, you can find an experimental one tailored for Riseup at [snapcraft](https://snapcraft.io/riseup-vpn), they've written a nice how-to as well: <https://riseup.net/betatest>
We're expanding now as well and are building a Windows installer, it's working pretty smooth, but still lacks a good firewall, we're looking forward to the near future to announce this more broadly.
* Code & Bugtracker: https://0xacab.org/leap
* Mailinglist: leap-discuss@lists.riseup.net
* Chat: ircs://irc.freenode.org/#leap if you don't have an irc client, you can use some gateway like [Matrix](https://about.riot.im/)
- @path_prefix = '2018'
= child_summaries :order_by => :posted_at
@title = 'Improved data synchronization'
@author = 'drebs'
@posted_at = '2018-04-27'
@more = true
@preview_image = '/img/pages/mozz/ascii.png'
Last year, LEAP [was awarded a grant from the Mozilla Open Source Support
program](https://leap.se/en/about-us/news/2017/mozilla-thanks) to [improve its
encrypted email
system](https://leap.se/en/about-us/news/2017/perf-improvements-soledad). We
would like to share with you some of the work that has been done as a result of
that, and also thank Mozilla for its initiative.
The general idea was to implement separation of data and metadata for encrypted
email storage and synchronization. That would allow for two fundamental
improvements: a better user experience (because the list of email messages
would then be able to be loaded before the actual contents of the messages),
and a better usage of systems resources (encrypted messages were previously
being treated as plaintext strings and thus consumed lots of unneeded memory
and cpu).
The [roadmap](https://0xacab.org/leap/soledad/wikis/2017-roadmap) included the
creation of a platorm to assess the performance impacts of proposed changes,
the actual implementation of the separation of data and metadata during
synchronization, and some specific performance and scalability improvements of
the sync server implementation.
The live benchmarking platform that was created proved to be very useful to fix
pre-existing performance issues and avoid unexpected performance bugs
introduced during development. A CI environment was used to run performance
test code for every commit made in the repository, and created graphs for
resource consumption (time taken, and amount of memory and cpu used during
execution). The quality of decisions made during development and the resulting
code were improved by having a live performance-wise feedback about proposed
changes.
As for data and metadata separation, changes to
[Soledad](https://leap.se/soledad) were made so that encrypted blobs can now be
delivered by external aplications directly to the user's database. The main use
case for this is for delivery of incoming email. LEAP's architecture is built
so that unencrypted email messages get encrypted before being delivered to the
user's mailbox. Metadata will soon be synchronized to the user's device, and
the user will be able to see the information associated with the message
(origin, date, subject, etc). But the actual content of the message will only
be downloaded and decrypted on demand, when the user clicks to read the
message.
Other than those major developments, the MOSS grant has also alllowed us to
experiment with multiple possibilities of performance improvements, as for
example server parallelization, usage of different asynchronous libraries,
Python 3 comparison, usage of proxies for load balancing, among others.
We very much appreciate the support from Mozilla that has allowed for
concentrated focus on Soledad. The work done within this contract has allowed
for the creation of a system to handle encryption and transfer of binary data,
leading to a much faster and scalable email solution. The critical
implementation of a benchmarking system produced clear data to find
bottlenecks, drive development, and allow for targeted changes to increase
speed and scalability of data encryption and transfer chain.
LEAP looks forward to applying that work to Bitmask Mail where end users will
reap the benefits. Development of this new blobs system and its future
integration with Bitmask Mail will be a critical step in bringing easy to
deploy truly secure email to a mass market.
@title = 'LEAP member received the 2018 Pizzigati Prize'
@author = 'isydor'
@posted_at = '2018-05-03'
@more = false
@preview_image = '/img/pages/tides_logo.png'
We are proud that [Tides](https://www.tides.org/) awarded LEAP
member Andre Bianchi the [2018 Pizzigati
Prize](https://www.tides.org/accelerating-social-change/2018-pizzigati-prize-andre-bianchi/). Thank you a lot for this recognition of the work done to make it
possible to freely communicate digitally and to support social change!
@title = 'Bit by Bitmask: what we\'re up to and what we\'ve thrown overboard'
@author = 'kwadronaut and some from kali'
@posted_at = '2019-07-04'
@more = true
@preview_image = '/img/pages/toolbox.jpg'
It's about time to fess up to our users: our idyllic ship that once sailed in the skies was a beautiful dream, but we all know that ships can't fly. We're now back to the basics, not just floating, but sailing. We've thrown e-mail and fat clients overboard, for now, and we're scraping rusty python 2 and Debian oldstable off our hull.
What does this mean? We're focusing hard on VPN: in the coming months we want to include [Pluggable Transports](https://2019.www.torproject.org/docs/pluggable-transports.html.en) together with [Calyx](https://www.calyxinstitute.org/). The trimmed down desktop client is a little bit more than a systray icon who handles all the hard work of configuring your VPN. [RiseupVPN](https://riseup.net/en/vpn) *is* this, obviously with their fancy bird graphics and configuration for their gateways. Bitmask as you know it in Android continues to hum along, bugs get fixed, polishing done, new releases will come. Besides that, we're experimenting with a [containerized platform](https://0xacab.org/leap/container-platform), which will make it easier to run a provider while simultaneously we'll get rid of old dependencies.
Dependencies like unmaintanable code: the javascript heavy Pixelated mail client. Or, because of the current providers engaging in planning, dropped authentication, so we don't have to cater for authenticated VPN, something that might change in the future, but currently we can drop CouchDB out of our tech stack and don't have to maintain a complex UI. This frees up a lot of brain power and makes it easier to move faster.
In short: Bitmask on your Android device, RiseupVPN to get you going on the desktop and LEAP, the platform when you want to start your own provider!
Hacking?
[RiseupVPN](https://0xacab.org/leap/riseup_vpn) is the /branded/ version of the minimal Go implementation of [Bitmask VPN](https://0xacab.org/leap/bitmask-vpn). It´s basically a wrapper around openvpn, with knowledge of what configuration files are expected to exist in a LEAP provider. The only user interface is a minimalistic systray icon that uses libappindicator.
The bitmask helper: lives for Windows and macOS in the [Bitmask VPN](https://0xacab.org/leap/bitmask-vpn/tree/master/pkg/helper/) repository. It implements a long-lived helper that runs with administrative privileges, for launching OpenVPN and the firewall. In OSX it is run as a LaunchDaemon, and in Windows we use nssm to run this helper. It communicates with Bitmask VPN via a local http service.
bitmask-root: for the snaps, in GNU/Linux we use a one-shot privileged helper that relies on policykit to elevate privileges without asking for password each time, instead of the long-lived helper that we use in osx and windows packages.
* Code & Bugtracker: https://0xacab.org/leap
* Android translations: https://www.transifex.com/otf/bitmask-android/dashboard/
* Desktop translations: https://www.transifex.com/otf/bitmask/RiseupVPN/
* Mailinglist: leap-discuss@lists.riseup.net
* Chat: ircs://irc.freenode.org/#leap if you don't have an irc client, you can use a gateway like [Matrix](https://about.riot.im/)
* ♥ donation: <https://leap.se/en/about-us/donate>
- @path_prefix = '2019'
= child_summaries :order_by => :posted_at
@title = 'So long Google Summer of Code!'
@author = 'kwadronaut'
@posted_at = '2019-02-03'
@more = true
@preview_image = '/img/pages/GSoC-icon-192.png'
We've enjoyed participating in the Google Summer of Code in the past and will probably do it again in the future. Alas, this year we will not participate in GSoC. Prioritizing ideas, mentoring students and being on top of the organizational aspects all requires time and energy that the current team would like to devote to our core pieces. Even with the talent that wants to dive into this project during their school breaks, time remains limited.
However, this shouldn't hold anyone back to contribute in their own time! Our Windows firewall is advancing, snap packages get pushed almost monthly (tailored for Riseup at [snapcraft](https://snapcraft.io/riseup-vpn)), we're experimenting with [pluggable transports](https://www.pluggabletransports.info/)… input is welcome in many areas: from translations to code over documentation to general praise and feedback.
* Code & Bugtracker: https://0xacab.org/leap
* Android translations: https://www.transifex.com/otf/bitmask-android/dashboard/
* Desktop translations: https://www.transifex.com/otf/bitmask/RiseupVPN/
* Mailinglist: leap-discuss@lists.riseup.net
* Chat: ircs://irc.freenode.org/#leap if you don't have an irc client, you can use some gateway like [Matrix](https://about.riot.im/)
* ♥ donation: <https://leap.se/en/about-us/donate>
- @path_prefix = '2020'
= child_summaries :order_by => :posted_at
@title = 'Packaging in GNU/Linux'
@author = 'meskio'
@posted_at = '2020-06-18'
@more = true
@preview_image = '/img/pages/gummi-penguins.jpg'
We get frequently asked why we don't do flatpack or appimage or arch packages
or... for our VPN. There are many distros and many package managers in GNU/Linux. Sadly our
time is limited and we have to decide what we focus our energies on. And
currently in GNU/Linux we are focusing our work on [snap
packages](https://snapcraft.io/riseup-vpn).
We know, snap has many problems. Packages often don't work well in distros not
based on debian ([#272](https://0xacab.org/leap/bitmask-vpn/-/issues/272),
[#77](https://0xacab.org/leap/bitmask-vpn/-/issues/77)). It's a centralized
platform, controlled by one commercial entity and [not everybody agrees with
their decisions](https://jatan.blog/2020/05/02/ubuntu-snap-obsession-has-snapped-me-off-of-it/).
Our primary target audience has always been the less computer-savvy users. In
GNU/Linux most of them use ubuntu. That has been our main reason to focus
our energies on supporting ubuntu first. And snap makes it very easy to include
software in ubuntu which is convenient too. Also the most used
distros around are debian based, and snap usually works well on those.
Knowing that not everybody likes snap, we produce [.deb
packages](https://riseup.net/en/vpn/linux#package-installation) as well and we
do our best to keep them up to date.
One of the other options we have explored is flatpack. I think its architecture
is great, its security is really nice and it solves some of the problems of snap
(it's not centralized, the control is in the users, ...). But flatpack is designed
to containerize the applications, making it impossible to package something like a
VPN, because it needs to modify the network configuration and the firewall
which is by design not allowed by flatpack. So flatpack is not an option for us.
Snap does containerize as well, but this is something that you can disable when
you make the snap by using the 'classic' mode. We do that to be able to package
a VPN into snap.
From the core team we might not have the time in the near future to work on any
other packages. But we will welcome any contributors. If you would like to
package the VPN for your favourite package manager we'll be really happy to
help. Don't hesitate to [open an
issue](https://0xacab.org/leap/bitmask-vpn/-/issues/new) to discuss it there,
pass by on
[irc](https://kiwiirc.com/client/irc.freenode.net:+6697/?nick=guest?#leap) or
write to our [mailing list](discuss-subscribe@leap.se).
@title = 'Smack the Virus!'
@author = 'kwadronaut'
@posted_at = '2020-04-10'
@more = true
@preview_image = '/img/pages/shield.jpg'
First things first: we're alive and kicking, staying healthy and physically distant. In fact, we are keeping our physical distance at a minimum of 450kms (that's 280 miles)!
If you are a Windows user, and you have tried to install or download [RiseupVPN](https://riseup.net/en/vpn) and ran into one of those big, red warnings?
It might not come as a big surprise to you, but virus and malware detection isn't a very precise or exact science. The heuristics used vary, but they somehow have to figure out what malware or a virus is and if they fail to detect one, no one will want to use them again. In practice this means that there are many false positives and alas, it has been happening too often with our software, even though we're doing our very best to keep you safe, sometimes it feels like a lottery!
We've been working hard to make this go away, and we think that the latest release makes some very significant progress. It is a painful process, sometimes very manual as we have to file disputes with the malware organizations. Have you tried the new version?
Remember kids, when Windows asks: "Possible virus! Do you want to report this?" think twice, you could be re-inforcing a false report and making our job harder!
Don't forget to stay safe from your ISP (or neigbor/partner/family/...) and use a trusted VPN provider like [the Calyx Institute](https://calyxinstitute.org/) or [Riseup](https://riseup.net/).
If you want to read more about this:
* https://0xacab.org/leap/bitmask-vpn/-/issues/222
* https://en.wikipedia.org/wiki/Rogue_security_software
* https://en.wikipedia.org/wiki/Antivirus_software#Issues_of_concern
When you want to help out:
* Code & Bugtracker: https://0xacab.org/leap
* ♥ donation: <https://leap.se/en/about-us/donate>
* Desktop translations: https://www.transifex.com/otf/bitmask/RiseupVPN/
* Android translations: https://www.transifex.com/otf/bitmask-android/dashboard/
* Mailinglist: leap-discuss@lists.riseup.net
* Chat: ircs://irc.freenode.org/#leap if you don't have an irc client, you can use a gateway like [Matrix](https://about.riot.im/)
Image by Ross Harmes: https://www.flickr.com/photos/rossharmes/4347385767
@title = 'On wireguard'
@author = 'meskio'
@posted_at = '2020-07-01'
@more = true
@preview_image = '/img/pages/wireguard.png'
Our VPN is built on top of [OpenVPN](https://openvpn.net/), a well tested and
widely used technology that has been around for almost two decades. As most
software with enough history it has grown with a lot of features and code
complexity. This is great as it has everything that we need to provide a stable
service, but at the same time it brings now and then security issues. The
OpenVPN team has been really good at handling them in a timely manner and in
LEAP we've been lucky to have designed our VPN in a way that prevented us from
being affected by most of the ones that have appeared in the last years.
Since a few years there is a newcomer to the free software VPNs:
[WireGuard](https://wireguard.com/). WireGuard uses nice modern cryptography
primitives, a pretty simple protocol and has a small code base. This makes it a
very fast VPN and probably less prone to security issues.
If WireGuard is so great why don't we ditch OpenVPN and use WireGuard instead?
WireGuard is great, but (yes, there is always a "but") it wasn't designed for
our use cases and it is not trivial to make it work for us.
WireGuard uses UDP, which is great for speed. But many of our users are in
networks that don't allow UDP traffic and for them to be able to connect we
need the VPN to support TCP. We are currently using OpenVPN on TCP mode, but
our plan for the future is to dynamically use UDP if available and if not to
fall back to TCP.
Some time ago there was a discussion about [TCP support in the wireguard
mailing
list](https://lists.zx2c4.com/pipermail/wireguard/2018-March/002496.html), with
proposed solutions like using
[ssf](https://github.com/securesocketfunneling/ssf),
[socat](http://www.dest-unreach.org/socat/) or
[udptunnel](http://www1.cs.columbia.edu/~lennox/udptunnel/). All of them sound
a bit hacky, one extra moving piece that can break.
Another problem is that WireGuard doesn't provide dynamic IP allocation. We
don't know in advance who will be connected to assign static IPs to each
client. We rely on OpenVPN to do it dynamically each time a client connects.
In WireGuard we would need to build some tooling around to do all this IP
assignment without the service operators getting the possibility to correlate
users and clients to IPs.
Besides all these technical issues there is a security issue, the
authentication protocol of WireGuard is not Forward Secret. That means an
observer recording all conversations only need to wait until the server long
term secret key gets compromised to be able to figure out which client produced
each connection. Let me remark, this doesn't mean that the attacker can decrypt
the traffic, they only see the authentication key, so they can pinpoint a
client being the same in different connections.
While this is a flaw, it is clearly an improvement over TLS 1.2 with client
certificates, which we are currently using with OpenVPN. Previously to TLS 1.3
(the latest version) if you authenticate the clients using a cert, which we use
to avoid having a list of users, the cert is sent unencrypted. That means that
currently an observer does not even need a compromised server private key to
track the users. We do minimize that by rotating the cert frequently and we are
preparing a migration to TLS 1.3, that solves this problem by transferring the
cert over a forward secret channel.
The dynamic IP allocation and the lack of forward secrecy for client
identifiers are being worked on in a separate tool named
[wg-dynamic](https://git.zx2c4.com/wg-dynamic/about/docs/idea.md) which does
handle the IP allocation and rotates the client identifier. So maybe in the
future those will be solved when wg-dynamic becomes more mature.
Right now for us adopting WireGuard would require a lot of development work to
get around those issues and to get a new technology stable enough to be used in
production. We already have our hands full maintaining the existing service and
prefer to prioritize our energies on providing a more stable and smooth VPN.
......@@ -6,61 +6,44 @@ a:visited {
// MASTHEAD
//
#masthead {
width: 100%;
margin: 0;
background-color: $masthead-bg-color;
border-bottom: $masthead-border;
@include gradient-vertical(lighten($masthead-bg-color,8%),$masthead-bg-color);
box-shadow: inset 0 0 8px 1px darken($masthead-bg-color, 8%);
header {
grid-area: header;
padding: $header-padding;
background-color: $header-bg-color;
text-align: center;
@include gradient-vertical(lighten($header-bg-color,8%),$header-bg-color);
box-shadow: inset 0 0 8px 1px darken($header-bg-color, 8%);
box-shadow-top: 0;
.masthead-inner {
height: $masthead-height;
@include cutout-menu(
$ul-id: top-menu,
$active-bg: $cutout-color,
$left-indent: $masthead-text-left-margin,
$small-left-indent: $masthead-small-text-left-margin,
$small-screen: $small-screen);
@media (max-width: $small-screen) {
height: $masthead-small-height;
> h1 {
color: $header-color;
font-weight: bold;
margin: $header-title-margin;
}
}
.logo {
background: $masthead-bg;
.nav-menu {
display: flex;
flex-wrap: wrap;
justify-content: center;
@media (max-width: $small-screen) {
background: $masthead-small-bg;
flex-direction: $nav-small-direction;
}
}
h1 {
// If we don't add the "a" here, on hover styles won't be affected
a.nav-item {
font-size: $nav-item-size;
padding: $nav-item-padding;
color: $nav-color;
background-color: $nav-bg-color;
font-weight: bold;
white-space: nowrap;
margin: 0;
color: $masthead-color;
line-height: $masthead-height;
font-size: $masthead-text-size;
padding-left: $masthead-text-left-margin - 2px;
@media (max-width: $small-screen) {
line-height: $masthead-small-height;
font-size: $masthead-small-text-size;
padding-left: $masthead-small-text-left-margin - 2px;
}
}
#top-menu a.tab {
font-weight: bold;
color: white;
background: rgba(0,0,0,0.5);
&.active {
color: black;
}
}
a.active {
background-color: $nav-color;
color: $nav-bg-color;
}
//
......@@ -257,3 +240,4 @@ img.left {
float:left;
margin: 7px 14px 0px 0px;
}
......@@ -21,25 +21,34 @@ $link-visited-color: darken($link-color, 15%);
$background-color: #fff;
$masthead-border-color: black;
$masthead-border: 1px solid $masthead-border-color;
$masthead-bg-color: #555;
$masthead-color: #fff;
$masthead-height: 128px;
$masthead-bg: url(/img/leap180.png) 0px 50% no-repeat;
$masthead-text-left-margin: 175px;
$masthead-text-top-margin: 45px;
$masthead-text-size: 36px;
$masthead-small-height: 96px;
$masthead-small-bg: url(/img/leap128.png) 0px 50% no-repeat;
$masthead-small-text-left-margin: 96px;
$masthead-small-text-top-margin: 20px;
$masthead-small-text-size: 24px;
//$tabs-small-size:
//$tabs-small-padding:
// Used for spacing between blocks
$main-v-spacing: 1rem;
//
// HEADER VARIABLES
//
// Free one line at the top of the page
$header-padding: $main-v-spacing 0 0 0;
$header-bg-color: #555;
$header-color: #fff;
$header-title-margin: 1rem 0;
$header-title-size: inherit;
//
// NAVIGATION MENU VARIABLES
//
$nav-color: $header-color;
$nav-bg-color: $header-bg-color;
$nav-item-size: 1.5rem;
$nav-item-padding: 0.6rem 1.2rem;
// On smaller screen, choose between horizontal (row) and vertical (column) menu
$nav-small-direction: column;
//
// OTHER VARIABLES
//
$cutout-color: darken($background-color,11%);
$background-color-start: darken($background-color,17%);
......@@ -47,7 +56,7 @@ $background-color-start: darken($background-color,17%);
$side-column-bg-color: #d0d0d0; // rgba(0,0,0,0.05); // #e3e3e3
$side-column-border-color: #aaa; // rgba(0,0,0,0.2);
$side-column-active-bg-color: #000;
$side-column-active-color: $masthead_color;
$side-column-active-color: $header-color;
$side-column-text-color: #000;
$side-column-indent: 15px;
......
......@@ -12,15 +12,15 @@ Bonafide is a protocol that allows a user agent to communicate with a service pr
* Authenticate with a provider.
* Destroy a user account.
Bonafide user SRP (Secure Remote Password) for password-based authentication.
Bonafide uses SRP (Secure Remote Password) for password-based authentication.
h1. Definitions
*DOMAIN* is the primary domain of the provider. This specified by the user when they enter what provider they want to sign up with.
*DOMAIN* is the primary domain of the provider. This is specified by the user when they enter which provider they want to sign up with.
*API_BASE* is the root URL of all the API calls. This is constructed from @api_uri/api_version@, where @api_url@ and @api_version@ are values found in the @provider.json@ file.
*ca.crt* is used to denote the provider's self-signed Certificate Authority certificate used to sign all the provider's server certificates, except for DOMAIN which uses a commercial Certificate Authority.
*ca.crt* is used to denote the provider's self-signed Certificate Authority certificate, which is used to sign all of the provider's server certificates, except for DOMAIN which uses a commercial Certificate Authority.
*ca_cert_uri* is the special URL that specifies where to download the provider's CA certificate (@ca.crt@). The value for @ca_cert_uri@ is found in @provider.json@.
......@@ -34,7 +34,7 @@ h2. JSON files
h3. GET DOMAIN/provider.json
The @provider.json@ file includes basic information about a provider. The URL for provider.json is always the same for all providers (`http://DOMAIN/provider.json`). This is the basic 'bootstrap' file that informs the user agent what URLs to use for the other actions.
The @provider.json@ file includes basic information about a provider. The URL for @provider.json is always the same for all providers (`http://DOMAIN/provider.json`). This is the basic 'bootstrap' file that informs the user agent what URLs to use for the other actions.
This request MUST be made no more than ONCE. All subsequent requests to update @provider.json@ must be made to @GET API_BASE/provider.json@.
......@@ -104,7 +104,7 @@ h1. REST API
h2. Version
The API_BASE for the webapp API is constructed from 'api_uri' and 'api_version' from provider.json.
The API_BASE for the webapp API is constructed from @api_uri@ and @api_version@ from provider.json.
For example, given this in provider.json:
......@@ -123,7 +123,7 @@ h2. Session
h3. Handshake
Starts authentication process (values A and B are part of the two step SRP authentication process).
The handshake starts the authentication process between a client and a provider. In the following example, values A and B are part of the two-step SRP authentication process.
<table class="table table-bordered table-striped">
<thead>
......@@ -141,7 +141,7 @@ Starts authentication process (values A and B are part of the two step SRP authe
</tr>
</table>
If the query_params leave out the @A@, then no @B@ will be included and only the salt for the given login send out:
If the query_params leaves out the @A@ parameter, then no @B@ parameter will be included in the response and only the salt for the given login will be sent in the reply.
<table class="table table-bordered table-striped">
<thead>
......@@ -161,7 +161,7 @@ If the query_params leave out the @A@, then no @B@ will be included and only the
h3. Authenticate
Finishes authentication handshake, after which the user is successfully authenticated (assuming no errors). This needs to be run after the Handshake.
Finishes the authentication handshake, after which the user will be successfully authenticated assuming there were no errors in the process. This needs to be run after the Handshake.
<table class="table table-bordered table-striped">
<thead>
......@@ -193,7 +193,9 @@ Variables:
h3. Token Authentication
Tokens returned by the authentication request are used to authenticate further requests to the API and stored as a Hash in the couch database. Soledad directly queries the couch database to ensure the authentication of a user. It compares a hash of the token to the one stored in the database. Hashing prevents timing attacks.
Tokens returned by the authentication request are used to authenticate further requests to the API, and are stored as a hash in the Couch database.
Soledad ([[https://leap.se/en/docs/design/soledad]]) directly queries the couch database to ensure the authentication of a user. It compares a hash of the token to the one stored in the database. Hashing prevents timing attacks.
h3. Logout
......@@ -219,7 +221,7 @@ h2. User Certificates
h3. Get a VPN client certificate
The client certificate will be a "free" cert unless client is authenticated. This certificate includes no identifying information that associates it with the user. Depending on the service level of the user, the certificate may have a common name that indicates that the certificate is valid for rate limited or unlimited bandwidth.
The client certificate will be a "free" certificate unless the requesting client is authenticated. This certificate includes no identifying information that associates it with the user. Depending on the service level of the user, the certificate may have a common name that indicates that the certificate is valid for rate limited or unlimited bandwidth.
<table class="table table-bordered table-striped">
<thead>
......@@ -235,9 +237,9 @@ The client certificate will be a "free" cert unless client is authenticated. Thi
The response also includes the corresponding private key.
h3. Get a SMTP client certificate
h3. Get an SMTP client certificate
The client certificate will include the user's email address and the fingerprint will be stored with the users identity and the date it was created. This is so that a provider can shut down a user's account if it is sending large amounts of Spam. Authentication is required.
The client certificate will include the user's email address and the fingerprint will be stored with the identity of the user as well as the date it was created. This is so that a provider can shut down a user's account if it is sending large amounts of spam. Authentication is required in order to receive an SMTP client certificate.
<table class="table table-bordered table-striped">
<thead>
......@@ -277,7 +279,7 @@ Create a new user.
h3. Update user record
Update information about the user. Requires Authentication.
Update information about the user. Requires authentication.
<table class="table table-bordered table-striped">
<thead>
......
......@@ -12,6 +12,112 @@ If you have your own ideas for projects, we would love to hear about it!
Bitmask Client Application
=======================================
Android
----------------------------------------------
### Improve logging in Log view.
Add a search for strings and include color highlighting for different log types.
* Contact: cyberta
* Skills: Android programming
### Review and improve the right-to-left layouts.
Improve User Experience for rigth-to-left languages like Arabic, Farsi and Hebrew.
* Contact: cyberta
* Skills: Android programming
### Improve accessibility.
Review accessibility and fix missing content descriptions
* Contact: cyberta
* Skills: Android programming
### Research on GPS spoofing.
* Research and document mechanisms based on other open source location spoofing apps
* Implement a prototype location provider that is capable to spoof the real location of a user
* Research, document and implement prototypically the communication/interaction between the location provider and the VPN
(Location provider shall be used if VPN is up and the corresponding setting was enenabled in Bitmask)
* Contact: cyberta
* Skills: Android programming
### Dynamic OpenVPN configuration
Currently the Android app chooses which VPN gateway to connect to based on the nearest timezones by time offset and establishes a configuration for connecting to it by a biased selection of options (ports, protocols, etc) from the set declared by the provider through the API. For cases where a gateway is unavailable or a network is restricting traffic that our configuration matches (e.g. UDP out to port 443), being able to attempt different configurations or gateways would help finding a configuration that worked.
* Contact: cyberta
* Difficulty: Easy
* Skills: Android programming
### Ensure OpenVPN fails closed
For enhanced security, we would like the VPN on Android to have the option of blocking all network traffic if the VPN dies or when it has not yet established a connection. Network traffic would be restored when the user manually turns off the VPN or the VPN connection is restored.
We've implemented the blocking VPN as a solution for non-rooted devices and we support Android's (since A. Oreo / A. 8) Blocking-VPN System setting. But the blocking VPN option does not play well with the setup of shapeshifter-dispatcher yet: shapeshifter-dispatcher needs to connect before OpenVPN, but Android blocks traffic until OpenVPN is up. Solutions for that problem needs to be investigated. Also, for pre-Andoid 8 *rooted* devices we could implement an iptables-based solution.
* Difficulty: Easy
* Skills: Android programming
## Improved UX
There are several areas where the user experience could be improved, particulary where it comes to our attempts to block unencrypted traffic.
* Priority: Medium
* Difficulty: Depends
* Skills: Android programming
Generic
---------------------------------------
VPN
----------------------------------------
### Gateway selection
Currently, the background bitmask daemon allows for gateway selection, but the current UI doesn't expose this. Consuming the information that the backend exposes, new widgets should be created in the Bitmask UI to allow the user to select the gateways, display different flags depending on the one that's being used, or display the gateways in a map.
* Contact: kali, meskio
* Priority: high
* Difficulty: easy
* Skills: JavaScript.
### Graph traffic statistics
The VPN service provides usage stats in a json document. A new widget is needed that plots both upload and download traffic along time, and also clearly displays when VPN is switched off.
* Contact: kali, meskio
* Priority: high
* Difficulty: easy
* Skills: JavaScript.
### OpenVPN usage improvements
Bitmask VPN works fine, but has many parameters configured statically like tcp and IPv4. It will be nice to acknowledge if the provider supports tcp and/or udp, try first (if supported) with udp and fallback into tcp if it can't connect. The providers can only provide IPv4 addresses to connect to, having support to stablish connections into the providers using IPv6 will be a nice thing to have.
The current firewall blocks all the IPv6 traffic from being routed over the VPN. There is new sources of privacy leaks from using IPv6 that were not existing into IPv4. It will be desirable to have some support for IPv6 in Bitmask VPN, allowing it and investigating what kind of firewall is needed to prevent IPv6 leaks.
Some ideas to improve security of the current VPN settings also involve coordinated changes between the platform and the client, so changes should be tested coordinatedly in both sides. Some topics in this category in the roadmap are: improving the ciphersuit selection, require a minimum tls version, renegotiate tls keys more often, blocking outside dns and implementing obfuscation and other circumvention measures against VPN blocking.
* Contact: meskio, kali, micah
* Priority: medium
* Difficulty: medium
* Skills: python, networking, openvpn, iptables
### iOS port of Bitmask
A basic port of Bitmask to iOS needs to mimick the behavior of the Android app: downloading configuration information from providers, building the OpenVPN command, and setting up the VPN.
* Contact: kali, meskio
* Priority: low
* Difficulty: medium
* Skills: iOS development.
Email
---------------------------------------
......@@ -40,11 +146,29 @@ Soledad Client
[[Soledad]] is our synchronized, client-encrypted, searchable database. It is written in Python, based on the Python implementation of U1DB (U1DB has similar features to Soledad, but has no encryption). There is also a C version of U1DB called libu1db. This project would be incrementally replace portions of the Python implementation with a version that can be compiled in order to make binding available on Android and iOS.
* Contact: drebs
* Contact: drebs, kali
* Difficulty: Hard
* Priority: High
* Skills: C/C++, using crypto libraries correctly, test driven development.
### Soledad standalone app
Soledad has been coded with the use-case of email as its primary goal. However, it is a generic encrypted and syncable storage, that could be useful to a wider community. In order for soledad to be useful, there are some parts that need to be decoupled from other pieces of the LEAP Platform (including a lightweight implementation of the token-based srp authentication system that can be configured in the absence of couchdb or the LEAP webapp). Once this is done, it would be very easy to code a demo application that showcases how the Soledad library can be used. Interesting project ideas are either a password manager, or an address book (see the section "New Services").
* Contact: kali, drebs
* Difficulty: medium
* Priority: High
* Skills: python, Qt, test driven development.
### JSON1 extension backend for SQLCipher
After U1DB was written, SQLite featured a JSON extension. This would greatly simplify the sqlite backend for Soledad, since we can store json documents directly into sqlite, and create complex indexes without the ned to use intermediate tables.
* Contact: drebs, kali
* Difficulty: hard
* Priority: High
* Skills: SQL, python or c.
Linux
---------------------------
......@@ -52,7 +176,7 @@ Linux
The Bitmask client application is entirely ported to Debian, with every dependency library now submitted to unstable. However, many of these packages are not in other flavors of linux, including RedHat/Fedora, SUSE, Arch, Gentoo.
* Contact: kali, micah, ivan
* Contact: kali, micah
* Difficulty: Medium
* Skills: Linux packaging
......@@ -60,28 +184,10 @@ The Bitmask client application is entirely ported to Debian, with every dependen
The Bitmask client application is entirely ported to Debian, with every dependency library now submitted to unstable. However, many of these packages are not in *BSD.
* Contact: ivan
* Contact: kali
* Difficulty: Medium
* Skills: BSD packaging
Mac OS
-------------------------
### Proper privileged execution on Mac
We are currently running openvpn through cocoasudo to run OpenVPN with admin privs, we should not depend on a third party app and handle that ourselves. The proper way to do this is with [Service Management framework](https://developer.apple.com/library/mac/#samplecode/SMJobBless/Introduction/Intro.html).
* Contact: ivan, kali
* Difficulty: Medium
* Skills: Mac programming
### Prevent DNS leakage on Mac OS
Currently, we block DNS leakage on the OpenVPN gateway. This works, but it would be better to do this on the client. The problem is there are a lot of weird edge cases that can lead to DNS leakage. See [dnsleaktest.com](http://www.dnsleaktest.com/) for more information.
* Contact: kali, ivan
* Difficulty: Medium
* Skills: Mac programming
Windows
-------------------------------
......@@ -90,7 +196,7 @@ Windows
The bundle needs to be a proper signed application in order to make it safer and more usable when we need administrative privileges to run things like OpenVPN.
* Contact: ivan
* Contact: kali, meskio
* Difficulty: Easy to medium
* Skills: Windows programming
......@@ -98,7 +204,7 @@ The bundle needs to be a proper signed application in order to make it safer and
Right now we are building OpenVPN with a manifest so that it's run as Administrator. Perhaps it would be better to handle this with User Account Control.
* Contact: ivan, kali
* Contact: kali, meskio
* Difficulty: Medium
* Skills: Windows programming
......@@ -106,7 +212,7 @@ Right now we are building OpenVPN with a manifest so that it's run as Administra
Currently, we block DNS leakage on the OpenVPN gateway. This works, but it would be better to do this on the client. The problem is there are a lot of weird edge cases that can lead to DNS leakage. See [dnsleaktest.com](http://www.dnsleaktest.com/) for more information.
* Contact: kali, ivan
* Contact: kali, meskio
* Difficulty: Medium
* Skills: Windows programming
......@@ -114,15 +220,15 @@ Currently, we block DNS leakage on the OpenVPN gateway. This works, but it would
We dropped Windows support because we couldn't keep up with all the platforms, Windows support should be re-added, which means making sure that the gpg modules, Soledad and all the other components are written in a proper multiplatform manner.
* Contact: ivan, drebs
* Contact: kali, drebs
* Difficulty: Easy to Medium
* Skills: Windows programming, Python
### Create proper Windows installer for the bundle
We are aiming to distributing bundles with everything needed in them, but an amount of users will want a proper Windows installer and we should provide one.
We are aiming to distributing bundles with everything needed in them, but an amount of users will want a proper Windows installer and we should provide one. There is some previous work involving building a bitmask installer from within linux, using docker, wine and MinGW.
* Contact: ivan, kali
* Contact: kali
* Difficulty: Medium
* Skills: Windows programming
......@@ -130,7 +236,7 @@ We are aiming to distributing bundles with everything needed in them, but an amo
All the python modules tend to be built with migw32. The current Windows bundle is completely built with migw32 for this reason. Proper Windows support means using Visual Studio (and in our case, the Express edition, unless the proper licenses are bought).
* Contact: ivan
* Contact: kali
* Difficuty: Medium to Hard
* Skills: Windows programming
......@@ -138,62 +244,21 @@ All the python modules tend to be built with migw32. The current Windows bundle
We have support for Windows 32bits, 64bits seems to be able to use that, except for the TAP driver for OpenVPN. So this task is either really easy because it's a matter of calling the installer in a certain way or really hard because it involves low level driver handling or something like that.
* Contact: ivan
* Contact: kali
* Difficulty: Either hard or really easy.
* Skills: Windows programming
Android
----------------------------------------------
### Dynamic OpenVPN configuration
Currently the Android app chooses which VPN gateway to connect to based on the least difference of timezones and establishes a configuration for connecting to it by a biased selection of options (port, proto, etc) from the set declared by the provider through the API. For cases where a gateway is unavailable or a network is restricting traffic that our configuration matches (e.g. UDP out to port 443), being able to attempt different configurations or gateways would help finding a configuration that worked.
* Contact: parmegv
* Difficulty: Easy
* Skills: Android programming
### Ensure OpenVPN fails closed
For enhanced security, we would like the VPN on android to have the option of blocking all network traffic if the VPN dies or when it has not yet established a connection. Network traffic would be restored when the user manually turns off the VPN or the VPN connection is restored. Currently, there is no direct way to do this with Android, but we have a few ideas for tackling this problem.
* Contact: parmegv
* Difficulty: Easy
* Skills: Android programming
## Improved UX
There are several areas where the user experience could be improved, particulary where it comes to our attempts to block unencrypted traffic.
* Contact: parmegv
* Priority: Medium
* Difficulty: Depends
* Skills: Android programming
Installer and Build Process
----------------------------------------------
### Reproducible builds with Gitian for bundles
We rely on a group of binary components in our bundles, these include libraries like boost, Qt, PySide, pycryptopp among many others. All these should be built in a reproducible way in order to be able to sign the bundles from many points without the need to actually having to send the bundle from the main place it gets built to the rest of the signers. This will also allow a better integration with our automatic updates infrastructure.
* Contact: ivan
* Difficulty: Medium to hard
### Automatic dependency collector for bundle creation
We rely on a group of binary components in our bundles, these include libraries like zmq, Qt, PySide, or openssl, among many others. All these should be built in a reproducible way in order to be able to sign the bundles from many points without the need to actually having to send the bundle from the main place it gets built to the rest of the signers. This will also allow a better integration with our automatic updates infrastructure.
The bundles are now used as a template for new versions, the first bundle was basically built by hand, adding one dependency after the other until it all worked. We would like to automate this process completely, since new dependencies tend to be added at certain points. One possibility would be to use PyInstaller dependency recollection code, another would be to use some of Python's module introspection to recursively collect dependencies.
* Contact: ivan, kali
* Contact: kali
* Difficulty: Medium to hard
### Lightweight network installer
The bundles are big. It would be great if we could reduce its size, but that's not always possible when you are providing so many different things in one application. One way to work around this would be to have a really tiny application that runs Thandy, has the proper certificates and has a tiny lightweight UI so that the user can install the bundle's packages one by one and even pick parts that the user might not want. Just want to run Email? Then there's no need to download OpenVPN and all the chat and file sync code.
* Contact: ivan
* Difficulty: Medium
* Skills: C/C++, Python
New Services
----------------------------------
......@@ -202,7 +267,7 @@ New Services
There are multiple password keepers that exist today, but they don't necessarily have a way to sync your passwords from device to device. Building a Soledad backed password keeper would solve all these problems implicitly, it's only a matter of UI and random password generation.
* Contact: drebs, ivan, elijah
* Contact: drebs, elijah
* Priority: Low
* Difficulty: Easy to medium
* Skills: Python
......@@ -211,7 +276,7 @@ There are multiple password keepers that exist today, but they don't necessarily
This idea is basically a simple note pad application that saves all its notes as Soledad documents and syncs them securely against a Soledad server.
* Contact: ivan, kali, drebs
* Contact: kali, drebs
* Priority: Low
* Difficulty: Easy to medium
* Skills: Python
......@@ -224,7 +289,7 @@ Miscellaneous
The idea is to allow or require tokens in the new user signup process. These tokens might allow to claim a particular username, give you a credit when you sign up, allow you to sign up, etc.
* Dependency: token-based signup in webapp API.
* Contact: elijah, ivan
* Contact: elijah
* Difficulty: Easy
* Skills: Python
......@@ -232,21 +297,21 @@ The idea is to allow or require tokens in the new user signup process. These tok
One thing that we really need is a team of people that is constantly updating their versions of the code and testing the new additions. Basic knowledge of Git would be needed, and some really basic Python.
* Contact: mcnair, elijah, ivan
* Contact: mcnair, elijah
* Difficulty: Easy to medium, depending on the QA team that is managed.
### Translations
Do you speak a language that's not English? Great! We can use your help! We are always looking for translators for every language possible.
* Contact: ivan, kali, ivan
* Contact: kali, meskio
* Difficulty: Easy
### Support for OpenPGP smart cards
A really nice piece of hardware is OpenPGP smart cards. What would be needed is a way to save the generated key in the smart card instead of in Soledad (or both, should be configurable enough) and then migrate the regular OpenPGP workflow to support these change.
* Contact: ivan, drebs
* Contact: drebs
* Difficulty: Medium
### Device blessing
......@@ -261,7 +326,7 @@ Add the option to require a one-time code in order to allow an additional device
There are situations where the service provider you are using through the bitmask client might want to notify some event to all its users. May be some downtime, or any other problems or situations. There should be an easy way to push such notifications to the client.
* Contact: ivan, elijah
* Contact: elijah
* Difficulty: Easy
* Skills: Python
......@@ -269,7 +334,7 @@ There are situations where the service provider you are using through the bitmas
Some users might be in situations where being caught with software like OpenVPN is illegal or basically just problematic. There should be a quick way to wipe the existence of the whole bundle and your identity from provider.
* Contact: ivan, kali, ivan, elijah
* Contact: kali, elijah
* Difficulty: Easy
* Skills: Python
......@@ -282,18 +347,18 @@ Soledad Server
### Add support for quota
Soledad server only handles authentication and basic interaction for sync, it would be good to have a way to limit the quota each user has to use and enforce it through the server.
Soledad server only handles authentication and basic interaction for sync. The recent blobs implementation has a very basic implementation of user quotas, but it needs to be made more efficient and cover some corner cases.
* Contact: ivan, drebs
* Contact: drebs, kali.
* Priority: Medium
* Difficulty: Medium
* Difficulty: easy
* Skills: Python
### Add support for easier soledad server deployment
Currently Soledad relies on a fairly complex CouchDB setup. It can be deployed with just one CouchDB instance, but may be if you are just using one instance you might be good enough with SQLite or other easy to setup storage methods. The same applies to authentication, may be you want a handful of users to be able to use your Soledad sever, in which case something like certificate client authentication might be enough. So it would be good to support these non-scalable options for deploying a Soledad server.
* Contact: ivan, drebs
* Contact: drebs
* Priority: Low
* Difficulty: Medium
* Skills: Python
......@@ -302,11 +367,20 @@ Currently Soledad relies on a fairly complex CouchDB setup. It can be deployed w
Bootstrapping Soledad and being able to sync with it is not a necessarily easy task, you need to take care of auth and other values like server, port, user id. Having an easy to use command line interface application that can interact with Soledad would ease testing both on the client as on the server.
* Contact: ivan, drebs
* Contact: drebs
* Priority: Low
* Difficulty: Easy
* SKills: Python
### Pluggable authentication system
Currently, soledad depends on couchdb and the LEAP platform to be deployed. For testing purposes, and for lightweight deployments, a simpler token-based authentication system would be very useful.
* Contact: drebs, kali
* Priority: medium
* Difficulty: easy
* Skills: python, twisted.
### Federated Soledad
Currently, each user's Soledad database is their own and no one else ever has access. It would be mighty useful to allow two or more users to share a Solidad database. This would allow us to use Soledad for a shared calendar, for example.
......@@ -381,7 +455,7 @@ Sometimes simple push notifications aren't enough, you may want to mail a newsle
### Add support for quota
Description: Once the Soledad server quota enforcement code is in place, it would be good to have the ability to configure the quota for a user and check the user's quota via the webapp.
Description: Once the Soledad server quota enforcement code is in place (there is some preliminar implementation in soledad using blobs), it would be good to have the ability to configure the quota for a user and check the user's quota via the webapp.
* Dependency: Soledad server quota enforcement.
* Contact: azul, elijah
......