[Freedombox-discuss] my summary of yesterday's Hackfest

[Matt Willsher]

On 28 February 2011 20:17, Jonas Smedegaard <dr at jones.dk> wrote:
> On Mon, Feb 28, 2011 at 03:55:10PM +0100, Michiel de Jong wrote:
>
>>  - xmpp is better than smtp in the same way "Internet Mail 2000" is: it
>> puts the burden with the sender, thus discouraging spam.
>>  - downside is, this means you would have to send your communications
>> through several different channels. people will still be using standard
>> email, without using freedombox, and will not be encouraged to use pgp
>> there.
>
> FreedomBox peers have no use for smtp if a better alternative (e.g. xmpp) is
> provided too.  Non-FreedomBox peers either are geeky enough to know how to
> setup the preferred mechanism of FreedomBox, or cannot be expected to use
> GPG anyways.

For Intra-peer communication sure. For outside communication xmpp
isn't widely adopted so SMTP is still required. Which ever protocol is
used should be as transparent to the end user as possible. e.g. If
their recipient has a xmpp address that is used otherwise SMTP is
used.

> PGP makes good sense to support for users.  Not sure, though, that it is
> sensible for a FreedomBox to store private keys on behalf of users, which is
> needed for the Plug to decrypt emails.

Where would the private keys live otherwise? Is the plug seen as trusted?

> Makes better sense to me for the box to stick to SSL encryption and store
> its own private keys for that - and only manage public keys of e.g. PGP on
> behalf of user(s) and peers.

I'm not sure if I've missed something here  (there is a lot to read on
this list at the moment!) but why are SSL private keys to be stored
and not PGP? Why make a distinction?

>> it was discussed that Asterisk has currently no consensus on how to
>> proceed with adding the necessary configuration options to debconf, so that
>> would sort of block the route for plugpbx's configuration going into a
>> debian package.

I'm a little bemused by the push to have the config controlled by the
package. The package is the software with rudimentary configuration.
Pushing corner case configuration to the package maintainer increases
their burden. Configuration IMHO should be separate from the package.
Again IMHO, RHEL/Fedora gets this better. Configuration is separate
from the package which should simply encapsulate the the original
software and all it to install following the distributions guidelines.
Further to this, if debconf or any debian specific configuration
management is used it makes porting to other platforms much more
difficult.

> I disagree:
>
> My preaching is that we should throw ideas here (what I call "dreaming), but
> engage in inventing/improving code _elsewhere_ and engage in package code
> for Debian _elsewhere_, and here work on _installing_ and _configuring_
> existing Debian-maintained code.

I agree we should draw on others' work as much as possible but we
can't mandate to them they need to improve their packages just for the
sake of FB. We need to use there tools (the bricks) and provide our
own configuration (the mortar).
Given FB is controlled centrally as a distribution cases like rubbish
handling of modified configuration files can be thoroughly tested. In
my dream work, the FBs maintain their own state and make sure that
they don't drift and stay aligned to their 'true' configuration.

> ....

I'll finish by saying if I'm mis-understanding something important
about your view of configuration please let me know. I just can't see
how it would work in practice for anything other than simple cases.

Regards,
Matt