Discussion May 2016

discussion@lists.fsfe.org

29 participants
21 discussions

Please help us spread the word on Roundcube Next
by Georg C. F. Greve 29 May '17

29 May '17

Dear all, In the spirit of full disclosure, let me start by pointing out that I am CEO and - along with other employees, some of whom you will also know - shareholder of Kolab Systems AG (https://kolabsystems.com) and that Kolab Systems has been the driving force behind Roundcube for the past years. Kolab Systems has also agreed to help the Roundcube Next team in its aim to refactor and build the next technology generation. So I am not neutral. That said, I genuinely believe it is extremely important for the Free Software community to get behind Roundcube Next and help us push it forward, as well as bring others on board with it. The longer story is here: http://blogs.fsfe.org/greve/?p=676 TL;DR, Part I: As a community we *require* technologies that compete with Google Apps, Office 365 and the likes in features, convenience, UI/UX, yet provide full control and freedom to users. TL;DR, Part II: Application Service Providers should get on board with that push *right now* because otherwise they will find themselves forced into becoming re-sellers for Office 365 and Google Apps -- and increasingly unable to compete with their features & networking effects. Some already understood this, and have joined the Roundcube Next community, such as cPanel (http://blog.cpanel.com/on-to-the-next/), Tucows, and now also Fastmail (http://blog.fastmail.com/2015/06/05/fastmail-supports-roundcube-next-develo…). But there are many more providers using Roundcube today who have not joined, nor have they contributed in the past. For them it should be obvious to join. And then there are those that have their own home-brew interfaces (such as Fastmail) who get the unique opportunity to become part of a new, growing community that will create a technology that will make them fully competitive against the "big clouds" in 18 months from now. Unfortunately, most of them have not realized this yet. So unless your provider is cPanel, Tucows, Fastmail or Kolab Now, all of who are part of this already, please encourage them to step up and join the community to push for Roundcube Next. Direct link for your convenience: https://www.indiegogo.com/projects/roundcube-next--2/x/4658765#/story Best regards, Georg -- Georg C. F. Greve <greve(a)fsfeurope.org> Member of the General Assembly http://fsfe.org/about/greve/ http://blogs.fsfe.org/greve/ http://identi.ca/greve

8 17

Uncorrectable freedom and security issues on x86 platforms
by Timothy Pearson 25 Oct '16

25 Oct '16

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 All, It has recently come to my attention that many in the free software movement are unaware of a relatively new development on x86 platforms that permanently removes the ability to use these platforms without also continually executing signed, proprietary code at the highest possible privilege level. All post-2013 (AMD) and virtually all post-2009 (Intel) systems contain this mandatory technology, and therefore, by design, can never be converted to run using pure FOSS. Prior to these changes projects such as coreboot could be used to replace the boot firmware with a FOSS alternative. The technologies in question are the Intel Management Engine (ME) and the AMD Platform Security Processor (PSP). Both serve effectively the same purpose; to ensure that the physical owner of the machine never has full control of said machine. These technologies, in turn, are used to implement various forms of remote control and Digital Rights Management (DRM) technologies, including Secure Boot, which even now requires FOSS users to purchase a license from Microsoft to boot FOSS on affected machines that lack an appropriate Secure Boot override. This includes, for example, many newer laptops. Major distributions have worked around this issue by purchasing a signing key from Microsoft for their binary packages, but the end user is unable to modify the signed software without a license from Microsoft, even though they have the source code available to them under the GPL. Furthermore, these signed, proprietary, binary-only firmware blobs must execute on the service processor(s) before the main x86 CPU cores are even released from reset (AMD), or will hard reset the entire system after around 30 minutes of non-operation (Intel). These blobs continue to operate on the service processor(s) as long as the system is powered on, and in the case of the Intel ME they also continue to operate while the system is powered off but still has access to power (e.g. plugged in or charged battery attached). These services processors have full access to system memory and all system peripherals, effectively giving the binary blobs executing on them a higher privilege level than even the operating system kernel. Due to the ability to access system peripherals, these proprietary blobs could easily contain code to exfiltrate encryption keys, remotely activate microphones and cameras, plant unwanted data, or simply remotely disable the ability of the machine to boot FOSS operating systems entirely. Finally, the Intel ME firmware can be forcibly updated by a remote entity; it is unknown whether the AMD PSP contains similar functionality at this time. So, what can an average user do? The obvious answer is to simply switch away from using the x86 architecture entirely. As Intel owns all rights to the x86 architecture, there will never be any new manufacturers licensed to make x86 chips, and therefore there will never be any competition to remove these DRM-laden antifeatures. There are numerous alternative architectures available, especially for those already using software with the source code available (i.e. FOSS), all of which can be licensed by other manufacturers should the need arise. ************************************************************************ General Overview of Alternate Architectures ************************************************************************ === ARM === While the ARM architecture may be more wildly known for locked-down computing products, there are several ARM devices on the market that allow full FOSS replacement of the boot firmware. Generally these are laptops, tablets, and embedded systems, with one example laptop being the ASUS C201 Chromebook: https://libreboot.org/docs/install/c201.html Using ARM in a mobile form factor also provides advantages of low cost and long battery life, albeit at the expense of overall system performance. === POWER === IBM has recently released their high-performance POWER8 architecture for third party licensing, and has also released a small treasure trove of firmware and documentation for these devices. POWER is the only architecture currently competitive with Intel in terms of raw performance, and boots using a fully FOSS firmware with no DRM antifeatures embedded. The primary disadvantage of power is cost, as it is currently targeted at the server and datacenter markets. We are attempting to bring POWER to the high-end workstation market in a FOSS-friendly form via the Talos™ Secure Workstation, but need additional interest to make this a reality: https://raptorengineeringinc.com/TALOS/prerelease.php === MIPS === Less well known than ARM, and with less vendor choice, MIPS is often overlooked. However, China has revived this architecture for general purpose computing with the Loongson core, and several machines are available using this processor. As a niche processor it has far worse performance than even a low-end ARM processor, but marginally better energy efficiency. Not recommended in light of ARM and POWER8: http://www.lemote.com/html/product/atx/2015/1227/8.html === RISCV === While this architecture is extremely limited in performance, price, and performance per watt compared to x86, ARM, or POWER, it is also one of the only fully open source CPU architectures available outside of an FPGA. and may eventually be competitive with MIPS in terms of raw performance. Currently there are no RISCV SoCs in production, however projects such as lowRISC aim to change that: http://www.lowrisc.org/ ************************************************************************ So, what are your thoughts on the current x86 proprietary software situation? Are you willing to continue to use FOSS software inside the ever-shrinking x86 "software jail", or are you possibly willing to give up some cost or performance advantages in order to retain full control of the software running on your hardware? This is a question that will need to be answered soon; the long-term consequences of a fully TiVo-ized computing world are not to be taken lightly, and thus far the free software community has put up very little resistance to the antifeatures being forced into modern x86 platforms. I hope to provoke wider discussion on these topics via this message. Thank you for your attention! - -- Timothy Pearson Raptor Engineering +1 (415) 727-8645 (direct line) +1 (512) 690-0200 (switchboard) http://www.raptorengineeringinc.com -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.11 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iQEcBAEBAgAGBQJXAoLsAAoJEK+E3vEXDOFbstsH/0BrB1VLKuSDDPdV4C7qJQOc 5euFCVc3cjZJhl+oGHQ2LuSuDM6J9DuYRxJQq53Xx9WYrNMSuqNjcnaagIhew+Ci ocMEQNB3G7ob4+56kyYrOTL7YoqrFcqa9Y5rpBXBt5ufnYt/g3n1Zin7xQycJ/rP ldLeADsaTJpsRgWLBTDnOAmMGBh1Xv4d4w1ZYAgoNfGJD6nc7NhihajIMZRIgHIn /Uo2brToF6exizHFMGWLwYdEKLOkoau7Bmz5yaGKI0JJF7hzq/G9dpecKf42G1ra Fr9q07JHCre7JJrq6SlbjapJyDB+OOK+YoFDjTsxaikV8E20AIQG4VkS3DsL7rU= =47/v -----END PGP SIGNATURE-----

6 13

system-hackers service agreement
by Daniel Pocock 27 Aug '16

27 Aug '16

Looking at the thread about the new blog team, it is clear that some things are dependent on the relationship that teams have with the system-hackers group Ignoring the current configuration of the systems, what is the ideal service that the system-hackers would like to be able to provide? E.g. - which OS/distribution? E.g. Debian - would more than one OS be feasible or required? (this multiplies support effort, should be avoided) - will services run in virtual machines and which technology will be used (KVM, XCP, Openstack, ...), e.g. will the blogging service run in a VM isolated from the services operated by other teams? - benefit: each team can receive major OS updates at different times - disadvantage: extra effort for system-hackers team, needs more IP addresses - how fast can packaged security updates (e.g. from Debian) be deployed? Will the updates be automatically deployed by cron or something, or will the team aim for a 24x7 support roster? In the latter case, are more volunteers needed in the system-hackers team? - how will major upgrades (e.g. from Debian 8.0 to 9.0) be deployed? E.g. aim to begin upgrade 3 months after the official release, individual teams using a particular server can veto the upgrade until 7 months have passed - which services must be supported by the system-hackers (I'd suggest backups, public web site, wiki, IP address allocation, SSL certificate creation, monitoring, Git, DNS, authentication/OpenID/LDAP, mail, mailing lists, SIP, XMPP and any services that the system-hackers may depend on in the course of their own activities) - are the system-hackers willing to support a database such as PostgreSQL for use by other teams? Can they provide a convenient way for members of other teams to take snapshots of their databases for use in test servers? - will the system-hackers allow members of other teams to use sudo? Maybe there are other things too, it would be good to see the system-hackers provide a list of what you would be willing to support and a separate list of what people think they need the system-hackers to support.

6 12

Re: Introducing our new blog team
by Daniel Pocock 13 Jul '16

13 Jul '16

On 17/05/16 09:06, Jonas Oberg wrote: > Dear Fellow, > > over the next months, we'll be rolling out an idea of fellow-run > services. As you know, the FSFE has been offering several services to > its volunteers over the years: a blog platform, an XMPP service, email > forwards, our wiki, and so on. > > One of our volunteers, Florian Snow, has volunteered to coordinate a > team of volunteers who will look at the possibility of taking over > maintenance of our blog platform and run this as a service for other > volunteers. > > By forming small volunteer teams around specific services, we hope > this will provide first the necessary autonomy to the individual teams > to run the service as they would want it run, and second, a useful > learning experience for the volunteers who take up the role of > maintaining a service. > Can you comment on what this means from a technical perspective? Does autonomy mean that volunteers will be able to pick any arbitrary version of an application and start running it on FSFE hardware? Or will volunteers run it on their own hardware and if so, how will things like authentication credentials be shared? In Debian we also have services that are maintained by individual developers, they fall into two categories: a) *.debian.net - these services run on a Developers' own servers, debian.net DNS is the only thing managed centrally, Debian provides no guarantees about the availability of such services b) *.debian.org - services running on Debian (DSA) managed hardware. Any applications used on such machines have to be packaged and backported to the stable release (e.g. jessie-backports). These have a higher level of availability and security updates. People who want to ensure a service is available 24x7 can generally help by ensuring all the software and dependencies are properly packaged and backported or helping raise funds for a developer to do that work. While it seems tedious at first, this is how we achieve security and availability. For example, when the developer of a package or backport is on vacation or retires, it is relatively easy for a security team member who never saw the package before to get involved and release an official patch for it. I often come across people who insist that they have to run the latest version of something from Git, usually with a hodge-podge of dependencies downloaded directly from different web sites. These types of arrangements are often very unique and very hard to support when the person is on holiday or decides to stop supporting it. Regards, Daniel

6 12

Fellowship Events broken?
by Christian Kalkhoff 29 May '16

29 May '16

Hi, i just tried to add an event to the Fellowship Events calendar in the Wiki. It suggested me a Pagename below "Events/2016/" which I happily accepted. Unfortunally my event didn't show up in the calendar. I moved some older events to the Events/2016 space and they disappeared from the calendar too. Unfortunally I cannot move the older pages back, because the wiki software insists, that the page already exist. So how is it supposed to be? Best, Christian -- Christian Kalkhoff - Softwarebefreier - software liberator Fellow of FSFE - Support FSFE! https://softmetz.de https://blogs.fsfe.org/softmetz

2 2

"10 reasons to base all your IT on the Linux ecosystem"
by Piotr Chmielnicki 28 May '16

28 May '16

Hello FSFE, (First post here.) Here is a small set of reasons why businesses should choose the Linux ecosystem to build their information systems: http://piotr.chmielnicki.com/10-reasons-to-choose-linux.html It is based on practical considerations, not on philosophy. I hope it could help people that are advocating for Linux. Feed-backs welcome. Have a nice week-end! Piotr Chmielnicki

1 0

Yubikey 4 becoming non-free
by Erik 'egnun' Grun 25 May '16

25 May '16

"I must, sadly, withdraw my endorsement of yubikey 4 devices (and perhaps all newer yubikeys), as apparently Yubico has replaced all open-source components that made yubikey NEOs so awesome with proprietary closed-source code in Yubikey 4s […]" https://plus.google.com/+KonstantinRyabitsev/posts/4a7RNxtt7vy Although I don't use the Yubikey myself, it is makes me quite sad that the developers decided to make one of their products non-free. Maybe we can convince them to readjust their decision. Regards -- egnun

7 14

Grobox: "Briar – Next Step of The Crypto Messenger Evolution"
by Erik 'egnun' Grun 24 May '16

24 May '16

Hey list, have you already heard about the new hot shit? Briar[1] is a "next level" messenger that is supposed to work without a central server and that wants to protect your meta-data through communicating via the tor network. What do you think? Is the project going to be successful? When you follow the argumentation of Moxie Marlinspike [2], then it's probably not. I hope that Briar is going to become popular and I'm going to download it as soon as it's available in the F-Droid store. Greetings, -- egnun ----- [1] https://blog.grobox.de/2016/briar-next-step-of-the-crypto-messenger-evoluti… [2] https://whispersystems.org/blog/the-ecosystem-is-moving/

5 7

A European Commission software, which tries to steal user's rights?
by Jann Eike KRUSE 24 May '16

24 May '16

Hi all! This is a message to the legal experts on this list: I find the EULA of the "Electronic Exchange System" (EES) rather nasty: [1] --- QUOTE: --- Without prejudice to the rights of users under the legislation relating to the protection of computer programs (which cannot be contractually denied), users may not in any way: (a) modify, translate or adapt the EES; (b) decompile or disassemble the EES; (c) copy the EES (or parts of it); (d) pass on, dispose of, grant as a sub-licence, lease, lend or distribute EES or EES documentation to third parties; (e) create any product or service substantially similar to EES; or (f) copy any ideas, characteristics or functions of EES. --- END QUOTE --- Point (c) is just a bit funny, because I just copied part of the EEC onto my computer screen by using it... ;) But really parts (e) and (f) are alarming. :-( It seems to me, that the Commission is actively supporting the concept of software patents. This reminds me of the Adobe EULA problem: https://en.wikipedia.org/wiki/Gnash_%28software%29#Adobe_Flash_Player_End-U… And then the EC tries to protect the validity of the EULA by adding "Without prejudice to the rights of users..." Any ideas what can be done about this? Are there activities regarding such? Comments? Greetings, Jann [1] http://ec.europa.eu/research/participants/api/authentication/termsandcondit…

3 2

an IT strategy that can be replicated
by Daniel Pocock 24 May '16

24 May '16

There have been a couple of threads on the list this week about the creation of individual teams to manage some FSFE services and the type of service that the system-hackers are offering to provide. One of the bigger issues associated with all this is the question of whether FSFE's IT model can be replicated by other organizations (including non-profits) of similar size. The default strategy for many organizations today seems to start with a Facebook group and graduate to Google Apps, possibly outsourcing a web site where money is spent on appearance and dodgy SEO services rather than development of any real functionality. This brings me to a few questions: - should it be a priority for FSFE's IT strategy to be easily replicated, so that we can say to other organizations that they can follow the FSFE sysadmin wiki and they will be up and running in a few hours? - are there other small non-profit organizations that already demonstrate best practice for volunteer-run IT with free software and should we build a list of them? For example, is FSF's or Debian's strategy considered suitable for other organizations to replicate? - going beyond the scope of Linux distributions like Debian, there are solutions like ClearOS[1] that aim to provide a turn-key office/small business solution, is anybody maintaining a list of these and would it be more productive for FSFE to move onto something like that and individual volunteers (such as the blog team) would contribute to that project? Regards, Daniel 1. https://en.wikipedia.org/wiki/ClearOS

4 7

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

2005

2004

2003

2002

2001

2000

Discussion May 2016