<br><br>On 1 March 2011 17:35, Jonas Smedegaard <<a href="mailto:dr@jones.dk">dr@jones.dk</a>> wrote:<br>> On Tue, Mar 01, 2011 at 03:51:05PM +0000, Matt Willsher wrote:<br>>><br>>> On 1 March 2011 01:26, Jonas Smedegaard <<a href="mailto:dr@jones.dk">dr@jones.dk</a>> wrote:<br>
><br>>>> On Mon, Feb 28, 2011 at 09:06:00PM +0000, Matt Willsher wrote:<br>><br>>> I, even as a geek, prefer unified interfaces and the tool to just do the<br>>> job. In the case of communication with other people I don't really care what<br>
>> protocol is used as long as it gets to the recipient and it is at least as<br>>> security as I believe it to be. For example, I type in a mail address<br>>> <a href="mailto:john@example.com">john@example.com</a>. This looks to see if <a href="http://example.com">example.com</a> and xmpp and if the users<br>
>> public key is known. If so it can be sent encrypted through xmpp. If not,<br>>> does the system have a SSL public key for S/MIME mail? If not, warn the user<br>>> the mail is sent in the clear. But don't be alarmist about it.<br>
><br>> In above, your expectation then is "insecure messaging"!<br><br>Fair point, but we don't want to alienate some of our target audience do we? For many it will mean "you can't communicate with your friends unless they two have a Freedom Box". Bootstrapping secure as default is a long standing problem that has yet to be solved adequately. Offering all methods but favouring secure is a step in the right direction, no?<br>
<br>>> The user should have to care about the underlying protocols just the task<br>>> they instructing the FB to do.<br>><br>> I fully agree - question is if "insecure messaging" is what they want.<br>
<br>If that is the only way the can communicate with someone they want to communicate with the answer is surely yes? <br><br>><br>>>> If I offered my friends a box that could do a new form of communication<br>
>>> which was more secure than those they already know of, they could easily use<br>>>> that (if the box wasn't difficult to setup or interact with).<br>>>><br>>>> If, on the other hand, I offered them a box with which to both do a new<br>
>>> more secure communication style and also communicate some of their old (e.g.<br>>>> classic mail) then the new tool needed not only to be good at the new thing<br>>>> but also be at least as good as the old one for old-style communication.<br>
>><br>>> There are only a certain number of paradigms regarding communication.<br>>> Off the top of my head there is the letter type email, the telegraph<br>>> style sms/tweet or the conversational style instance messages. There<br>
>> is some over lap with the distinction being length of message - email<br>>> is suited to long communication like the one we are writing here, SMS<br>>> and IM suited to short items.<br>><br>> You tell me that our users cannot comprehend a new paradigm called "secure<br>
> mail-style messaging", so for the sake of user-friendliness we need to drop<br>> the "secure" part?<br><br>No, not at all. I'm saying that the secure can only be an option if both ends support it. Thing is most users don't actually care that there mail might be read or intercepted. Those that do are already using encryption.<br>
<br>> I agree with your summary - We seem to disagree on what to offer:<br>><br>> For "freedom to send email-style messages" they do not need our box.<br><br>Agreed to a limit. The box would still offer decentralisation away from the likes of google and hotmail.<br>
<br>> I want us to offer "freedom of mail-style messaging without spying" which<br>> can only work for FreedomBox peers (and geeks setting up same technologies<br>> as we are "boxing"), not their old email- or MSN- or Facebook-friends.<br>
<br>I agree but going from the situation now (little to no security) to your dream is a huge step. I think we need to have bridge to steer down that path. <br><br>> Seems you want us to offer "freedom of mail-style messaging, without spying<br>
> whenever possible".<br><br>Yes, initially, until the ground swell towards security by default exists. Usability and putting these tools in the hands of the masses is to me what FB is about. I'd be quite happy for 0.1 to just offer mesh or just offer messaging in some easy to use form. This project has a long road to utopia I believe. <br>
<br>> I want our users to trust our box, not gamble with it.<br><br>I want us to have enough users to make this something other than a niche device.<br><br>> Just as cellphones did not also cover fax, and just as Facebook does not<br>
> also cover email, our tool does not cover related but less secure messaging<br>> paradigms.<br><br>How do we market that to an audience that, on the whole, cares more about who they communicate with not how. And even the who is open to question due to the lack of security measures. <br>
<br>><br>> Whenever sensible we should cover both freedoms and non-freedoms. Sensible<br>> examples are blogging and tweeting: Publish to the world on your own device,<br>> and optionally replicate into data silos like Twitter and Facebook (maybe<br>
> just an excerpt to help tell those still trapped inside those silos that the<br>> world outside is more comprehensive). The freedom here is to aboid central<br>> logging at <a href="http://blogger.com">blogger.com</a> and the silos, and it is ok to relax that to only<br>
> _mostly_ avoid that logging.<br><br>Decentralisation is a key tenant to me but again, provide a bridge to utopia is better than nothing.<br><br>> But when the freedom is "messaging without spying" where the _content_ needs<br>
> discretion, not transport activities of it, then being relaxed is more<br>> problematic.<br><br>But if that is an important goal then all parties will assure their security. If what they are doing is important enough they want security they will find it. FB is about making it easier to access, to me.<br>
<br>>> My point is rather: why not just use X.509 keys and certs and why use<br>>> GPG/PGP at all? X.509 is multi purpose, well adopted and well trusted.<br>><br>> Perhaps we agree,then :-)<br><br>I think we probably agree on more than it first appears :)<br>
<br>> It makes sense for me that the box contains private key(s) for its own<br>> identity/identities.<br>><br>> For identity handling of its user(s), it makes sense to me to *not* handle<br>> private keys, only public keys, even for the owner of the box.<br>
><br>> ...and it might make sense to then not handle GPG at all, if we judge that<br>> our target userbase is too non-geeky to sensibly handle GPG, but only can<br>> comprehend to put trust in deviced, not in humans behind them.<br>
<br>I see your point and the large response to this question has clarified a lot for me. I agree that a separation of device identify and user identity is ideal. Perhaps smart cards or similar technologies would help facilitate this result? <br>
<br>>>> I see Debian packages not only as "compiled code" but as "maintained<br>>>> system-integration of code". Configuration is an essential part of system<br>>>> integration. And I expect Debian package maintainers to not only provide me<br>
>>> what upstream provided them, but also handle migrations of e.g. changes to<br>>>> some config options - seemlessly if possible but asking me if no single<br>>>> upgrade path is possible to resolve without my help.<br>
>><br>>> But these configurations can be large and complex. Even capturing simple<br>>> cases is difficult in many cases. Take BIND, Asterisk, Apache even sudo.<br>>> They are are complex pieces of software with complex configuration<br>
>> requirements. There is no way the package maintainer can make sure their<br>>> changes don't tread on the toes of a current configuration, and nor should<br>>> the dictate the way in which software is configured.<br>
><br>> This is too big a subject to cover extensively in one email thread, I think.<br>> :-)<br><br>I though the very same thing when I came to this part of the mail! :D<br><br>> Actually, of your examples mentioned above, the Debian packaging of sudo now<br>
> (since Squeeze) offers a config.d mechanism that other packages can hook<br>> into, and packaging of apache has for some time offered a (better!)<br>> combination of config.d and symlink-enable-disable script.<br>
<br>But something still needs to managed though linked files. <br><br>> In fact I have borrowed the apache mechanism for the boxer tool I recently<br>> mentioned here on the list :-)<br><br>Yes, I saw that.<br><br>>> My view of a package, specifically debs because this doesn't apply to<br>
>> plenty of other package system, is that it should provide basic setup<br>>> options to glue the software to the current installation. It makes sense to<br>>> give a basic configuration out of the box for those learning the system, but<br>
>> a competent admin will soon find the simple cases that can be encapsulated<br>>> by the packages to be restrictive and counter productive.<br>><br>> FreedomBox do not have the luxury of "a competent admin". FreedomBox needs<br>
> to work "out of the box". Or even, ahem, "in the box" :-D<br><br>To me the 'competent admin' is the configuration management tool developed by real competent admins and developers. <br><br>
> When working with configs, it is quite understandable that at first you see<br>> us as "admins" of the box. But then comes a new release of Debian and we<br>> learn that the model of os acting as admins do not really fit: We _deploy_<br>
> systems and then loose contact with them. We are _deployers_, not admins.<br>> And as such we are much better off passing _all_ of our customizations to<br>> pristine Debian packages into Debian than trying to work from that new role<br>
> of "deployer" which neither upstream (Debian or upstream coders) nor our<br>> users can comprehend.<br><br>I do not believe that we should be asked the packagers to take the role of administrator, which to me is what the above implies. I see you point. It's just alien to me and I think it puts too much onto the package maintainers. <br>
<br>> Users get their stuff from one provider. They should not care which roles<br>> was involved in which parts of the assembly of it.<br><br>I agree. They shouldn't even need to know what OS is under the hood. <br>
<br>> Debian provide stuff for their users. They should not care which kind of<br>> user (derivative distro, deployer, end-user) is targeted.<br><br>> We perfectly agree that end-users are on their own if "hacking on top".<br>
><br>> The issue I am talking about is that _we_ hack on the _Debian_ stuff and<br>> then pass it on to our users. Then later it explodes in _their_ faces when<br>> _Debian_ wants to upgrade a config which _we_ hacked on.<br>
><br>> You may argue that the box never changes. Should not ever be upgraded to<br>> newer versions of Debian. That is indeed an approach, but not a sensible<br>> one long-term IMO.<br><br>I would expect that Debian will not make config level changes with in a release? So if we stayed with, say, squeeze for now we wouldn't face the issue you're outlining because the upstream shouldn't be trying to jump all over our configuration. Or is that not the case?<br>
For going between major releases a careful and staged approach is needed. For many, if not most, of the packages there will be little change. The major upgrades where there is major config changes may need some work, but I don't see why a configuration management model outside of the packages would be problematic. I has many benefits, including maintaining the configuration, making sure that permissions are maintained and gives a consistent method of orchestrating the system. Done correctly this kind of orchestration could server as a model for other systems. Perhaps this isn't the project to do some adventurous architecting. <br>
<br>> I find it unlikely that next generation of freedom fighters will want to<br>> work on Plug devices.<br>><br>> But I find it highly likely that the freedom-enabling technologies that they<br>> will want to include in their designs share many similarities with our<br>
> current project.<br>><br>> So I find it most likely that all contributions survive long-term if<br>> integrated with the various packages rather than is tied to the specific<br>> solution we aim at.<br><br>
That depends on how good it is. I can see your point about the packages, and I can see there are benefits, I just don't see how it can be a complete solution to the issue of configuration management. There needs to be other methods. <br>
<br>> you see Debian packages and their usage more separate than me.<br><br>Yes. My background is Solaris and RHEL. The explicitly do not take user input as part of their installation. They provide reasonable defaults and let the users tailor the installation via 'traditional' means. I like this approach. It maintains separation. I've worked on both sides of the fence and I like a clear divide. <br>
<br>> Yes, esp. complex packages are difficult to setup automated, but it is a<br>> goal of Debian to do so. So please help challenge Debian to improve in this<br>> area!<br><br>I believe the problem domain is so complex for anything but basic packages that it should be part of the package system. Before you know if you have xml parsers and even specific grammer parsers as part of the packaging infrastructure. As a packager all I care is that the software ends on the system and will run. What the end user does with it is up to them. <br>
If you've not read the cfengine tutorial or maybe even better Mark Burgess papers on promise based systems for automation I implore you do to so. If offers a degree of flexibility that packaging within a box just can't deliver and offers a consistent model across any scale of architecture. <br>
<br>> how do you mean? Each and every package in Debian has at least one<br>> volunteer already: Miminum requirement is to file sensible bugreports.<br><br>If they loose a key maintainer you could end up with a package that isn't 'correctly' maintained between releases. <br>
<br>> You believe that needed configs are impossible for thousands of Debian<br>> volunteers to automate.<br><br>I believe providing all things to all people through the packages is not the place it should be. <br><br>
> I agree with you that us tens of FreedomBox volunteers are able to compose<br>> needed configs by hand.<br><br>No, we let a configuration management tool do the heavy lifting. Is this the project to develop that? Maybe not. But I can't see the Debian contributors being able to come together to deliver everything we need to get FB together. There will have to be some other management system available to us. <br>
<br>Further to all of this the UI needs to be decoupled from the package and software management. We really can't have a UI making direct root and configuration calls. There has to be a controlled intermediary which just accepts the data to be configured and applies it. <br>
<br><br>> What I find Hubris is to maintain it on our own.<div><br></div><div>Ah heck, I hack at Perl. Hubris is a good things, dangnabbit (along with that there laziness and impatience) :)<br><br></div><div>Gosh that's a long old mail. I really need to start showing something for it rather than just giving it all this talk. </div>
<div><br></div><div><br></div><div><br></div><div><br></div>