The ownCloud community has long suffered from a gap between users and developers:
In the forum (and to a lesser extend on the user mailinglist and IRC), a lot of regular volunteers have very successfully covered users’ issues in getting up to speed.
On the mailing lists and on GitHub, sometimes miles high above and in a mostly disjointed community developers have been developing away.
Between the two, there has been a big divide that was unsatisfying. Also neither Forums nor Mailing lists are a good fit for agile communities these days.
So let’s fix this! The forum moderators and sysadmins, have long been wanting to move off our old trusted forum for this reason, and had decided to use Discourse. Now we finally have a new host, courtesy of ownCloud GmbH, to carry a successor.
I want to give a big shout out to RealRancor and tflidd, who have done terrific work on migrating the FAQs and vital articles to the new platform. Next, we’ll put the forum into read-only mode and will archive its contents. ownCloud Central will take over. We also migrated all accounts from the old forum. Let’s continue to make ownCloud awesome together!
Last week saw several events in Berlin’s Station event location that also featured ownCloud in one way or the other. The first, re:publica, is probably mostly known by bloggers and internet activists. Titled Into the wild, an obvious tongue in cheek about the unsafe and well-surveilled place the internet has become, it was a great place to talk about ownCloud. Frank took that opportunity and was received by a packed room, to which he delivered a talk about ownCloud, despite The Hoff performing on Stage 1 at the same time.
Jos and Arthur at a freshly set up booth.The last day of re:publica coincided with the first day of LinuxTag 2014, which moved from Fairgrounds to Station Berlin. This brought a lot of new people to visit our booth, which ownCloud shared with openSUSE and KDE, courtesy of our new Community Manager Jos.
On Thursday, Frank and I also got invited and interviewed about ownCloud by the Sondersendung Podcast. If you can understand German, you can listen to our 15 minute interview .
ownCloud is a proud sponsor of LinuxTag 2014.At the presentation area of our booth, Arthur and Georg gave workshops on writing your first ownCloud app, while I was covering the details of the synchronization process in depth. Every day of LinuxTag, quite some people took the chance to listen and ask questions.
Others just walked up to our demo point for a quick demonstration of ownClouds capabilities and concepts. Some inquired about the improvements from earlier versions they have used, and most were impressed by the progress that ownCloud 6 and ownCloud Client 1.6 represent. Since LinuxTag joined forces with droidcon, we also had lots of questions on our mobile integration for Android (and iOS, :), for both ownCloud app and calendar/addressbook sync.
In total, LinuxTag has been a really great show this year, which was mostly owed to the co-location with other events and the more central location. We’re looking forward to LinuxTag 2015!
Arthur explaining how to write your own ownCloud app.The workshop on file synchronization.
Throughout the recent months (and particularly: weeks), people have asked me how to properly secure their SSL/TLS communication, particularly on web servers. At the same time I’ve started to look for good literature on SSL/TLS. I noticed that many of the “guides” on how to do a good SSL/TLS setup are actually cargo cult. Cargo cult is a really dangerous thing for two reasons: First of all, security is never a one-size-fits-all solution. Your setup needs to work in your environment, taking into account possible limitation imposed by hardware or software in your infrastructure. And secondly, some of those guides are outdated, e.g. they do neglect the clear need for Perfect Forward Secrecy, or use now-insecure ciphers. At the worst case, they are simply wrong. So I won’t be providing yet another soon-outdated tutorial that leaves you non-the-wiser. Instead, I’ll share my collection of free and for-pay documents, books and resources on the topic which I found particularly useful in the hope that they may help you in gaining some insight.
Introduction to SSL/TLS
If you’re unfamiliar with SSL/TLS, you definitely should take half an hour to read the Crypto primer, and bookmark SSL/TLS Strong Encryption: An Introduction for reference.
So you want to get your hands dirty? Check your server setup with Qualys SSL Labs’ server test. Make sure you fix the most important issues. You should at least be able to get an “A-” grading. If you find yourself in trouble (and are the administrator of an Apache or nginx setup), you should read the OpenSSL cookbook. Professional system administrators should have Bulletproof SSL/TLS and PKI on the shelf/eBook reader.1)
If you find yourself with too little time on your hands, you can skip through to Mozilla’s awesome config tool which will help you with setting up your SSL vhost for Apache, nginx and HAproxy. However, some background may still be needed. You will find it on Mozillla’s Cipher recommendation page and the OpenSSL cookbook.
Qualys SSL Labs is a web site that can analyze the quality of a given SSL/TLS setup (HTTP only) using a nice rating scheme 2) and providing hints on how to easily improve your setup.
Bulletproof SSL/TLS and PKI — Subtitled The Complete Guide to Securely Using SSL/TLS and PKI in Infrastructure Deployment and Web Application Development, this book is still work in progress (and is constantly updated, also according to readers feedback). Its author, Ivan Ristić, is also the guy behind ssllabs.com). Purchasers will receive updates to the eBook once finished. You can also purchase a hard copy
OpenSSL Cookbook — Extended excerpt from Bulletproof SSL/TLS and PKI. Suitable to secure your web server. Free download (requires registration).
If you are a dedicated IT professional, you should not miss the next section. Although it’s not crucial for those wishing to “simply secure their server”, it provides those who are responsible for data security with a clear understanding of the numerous theoretical and practical limitations of SSL/TLS.
SSL: Paved with Good Intentions: Presentation on history and weaknesses of SSL/TLS by Richard Moore, CTO at Westpoint Ltd and the maintainer of the Qt SSL/TLS stack.
20 years of SSL/TLS Research Dissertation providing an excellent background on the pitfalls, attacks and risks of SSL/TLS. Suitable for non-scholars (and highly recommended). You may skip the math.
The case for OCSP-Must-Staple: Great commentary on what is needed for SSL/TLS beyond OCSP Stapling to have good support for certificate revocation.
Sometimes you need to debug errors during the SSL handshake. While a bit primitive, OpenSSL’s s_client tool is the weapon of choice. When it comes to monitoring SSL/TLS encrypted communications, use mitmproxy or Charles. They need to be added as proxies, but can also intercept PFS connections, due to their active MITM position.
sslyze – a command line script to check SSL/TLS on servers (Python)
cipherscan – command line client to check effectively supported cipher suites (Bash)
openssl s_client is a command line tool that provides details on the handshake phase and establishes a secure connection. Use it to debug problems with certificate chaining, OCSP stapling, etc.
This list is not exhaustive and if you have more suggestions, please go ahead and post them in the comments. I’ll be happy to add them. Finally, just like with system administration in general, you’re never “done” with security. SSL/TLS is a swiftly moving target, and you need to be aware of what is going on. If you are an IT professional, subscribe to security mailing lists and the announcement lists of your vendor. Finally, while I’m aiming to update this page, there’s never a guarantee of up-to-dateness for this list either.
Update (22.04.2014): Don’t miss the discussion on this article over at Hacker News.
Article History
21.04.2014 – Initial version
21.04.2014 – Added “The Case for OCSP-Must-Staple”, Mozilla Cipher suite recommendation
22.04.2014 – Updated to add sslyze and cipherscan, added HN link, fixed typos
02.05.2014 – Add “Analyzing Forged SSL Certificate” paper
19.12.2014 – Add Mozilla SSL Generator, updated text on book availability
1) I do realize that I am courting Ivan a lot in this section and that relying on only an a single external web service that can go away any day is not a good thing. At the same time I think that the handshake simulation and the simple rating process are priceless, as such assessment cannot be trivially done by people whom’s life does not revolve around crypto and security 24/7. At the same time, I’m happy for any pointers towards other, user friendly tools.
2) While blindly following the rating can easily lead to the establishment of cargo cult, ssllabs.com is continuously updated to only give those a good grading that follow the best pactices. Again: Avoid Cargo Cult, make sure you have a good idea of what you are doing.
This release was developed under the promise that it would improve performance1), and we have made tremendous improvements: Using a new Qt-based propagator implementation, we can now perform multiple simultaneous up- and downloads. We still provide the old propagator for certain situation where it’s more suitable, such as for situations where bandwidth limitation is needed.
Furthermore, the sync journal access code has been significantly optimized. It paid tribute to most of the high CPU load during the mandatory interval checks. CPU usage should be much lower now, and the client should be usable with more files at the same time.
Windows users should also find update times improved as the time spent in file stat operations has been reduced. Mac OS X users will enjoy the benefits of a much improved file watcher. To be able to use the more efficient API, 1.6 drops support for Mac OS Snow Leopard (10.6) and now requires Mac OS 10.7 or better.
At the same time, production releases are now using Qt 5 rather than Qt 4 on Windows and Mac OS X2). This fixes a lot of visual bugs in Mac OS X, especially for Mavericks users, and allows us to profit from improvements in the SSL handling, especially on the Mac.
We also implemented an item that was on many peoples wish list: a concise sync log. Next to the database, the sync folder now holds a hidden file called .owncloudsync.log. It will store all sync processes in a minimal CSV file. Contrary to previous logging facilities, it always logs and only collects information relevant to the actual sync algorithm decisions.
Because this tour was not as colorful as the previous one, let’s close this blog post with a feature contributed by Denis Dzyubenko: The settings dialog on Mac OS X now has a native look & feel:
1) Now that while the client is multi-threaded, you may find that the transfer time still doesn’t improve as much as you would expect. This is due locking issues on the server which prevent efficient parallel transfers. This has been improved in 1.7, and could potentilly improved even further by implementing support for X-Sendfile/X-Accel-Redirect in SabreDAV, the DAV framework used by ownCloud server.
2) We can’t do the switch even on modern Linux distributions mostly due of the poor support for modern and divergent Systray/Notification area support in Qt5: Even in Qt 4 we could only use it because Canonical had patched their Qt to make QSystemTrayIcon work with Unity, which they have not ported to Qt 5 yet. Gnome 3 also hides away traditional Systray icons way to well, not to speak of Plasma. Any leads would be helpful.
A packed room listens to the talks at the ownCloud 5 release event.(Deutsche Version drüben bei Arthur)
With the final release of ownCloud 6 imminent, it is time to celebrate!
This time, BeLUG, who is also running an ownCloud installation for their members, was kind enough to host the Berlin release event. We’ll have short talks by both developers and admins, free pizza and beverages at affordable prices.
Talks (~20 min each):
ownCloud 6 Tour — Arthur Schiwon, ownCloud
Improvements in ownCloud Client 1.5 — Daniel Molkentin, ownCloud
ownCloud @ BeLUG, an Admin Perspective — tba, BeLUG
First of all, we have completely redesigned The Propagator. It’s the component that is responsible for actually performing all the changes that earlier phases in a sync run have determined to be required. It is vital that the propagator does things in a clever way, and the new design allows just that. The new propagator writes changes to the sync journal as they happen, and does not rewrite the journal after every run. This means that sync runs can be paused or even terminated, and on the next start, the client will pick up where we left it. This is especially important for the initial sync which may take quite a while.
Next, we sped up sync runs significantly. If you are using an up-to-date server version, ownCloud Client 1.5 only requires one instead of three round trips to get a simple file uploaded, since the server can now accept the modification time as a header value. This will especially help with small files.
Another thing this release gets straight is support for remote moves: The old propagator handled them in terms of delete and re-download, which is a bit silly to begin with. Finally, with the new propagator, we can correctly handle moves for what they are, which turns pushing Megabytes of files into a simple mv instruction. In order to detect moves reliably, we now use file IDs next to ETags other meta data, which requires ownCloud 6.0 on the server side.
When you deleted folders, the old propagator would work strongly recursive, meaning a deletion one-by-one. This had several implications, as the non-atomic way of the old approach was problematic as it allowed for unexpected errors to happen. Also every file would be moved to the trash separately (assuming you had the trash app activated), making restore rather painful. The new propagator does away with all this: If you delete one directory, only the directory with all its structures will be moved to trash. As a side effect, this makes the delete operation on the wire much faster.
Handling Error Conditions
Ignored and blacklisted files now get featured more prominently.There are some situations where syncing a file cannot succeed, for instance when the shared folder on the server cannot be written to. Previously, we would try again and again and again which caused system load.
Now in cases like read-only shared folders we actually know that we will never succeed — until someone changes permissions on the server, that is. So now the client will put files it cannot write to on a black list. Only when the file or one of its parent directories changes, we check again if we are now allowed to write. This should improve traffic and CPU load a lot.
Another issue we addressed was our new handling of files that are on the local ignore list or which contain characters that cannot be replicated to other operating systems (which is an ongoing discussion). Most people were well aware that it would never work, making the (i)-indicator we were showing an annoyance. We also indicated the failure in a log dialog, which turned out to be too well-buried.
In the new release, the sync log has been renamed “Sync Activity” and was placed more prominently as a top level item. It shows all files that have been synced, as well a items that could not be synced at all. The systray icon will not show the (i) icon anymore.
One Account to rule them all
Another major change won’t be visible to you until you look at the source: The Account. It has been introduced as a first step to implement support for multiple accounts in forthcoming versions. For now, it suffices to say that this change has made the internals easier to understand and extend.
Password handling and Signing out
The client when singed in…A direct implication is that the client now has a folder-spanning notion of being on- or offline. In addition to that, you can now also sign out. This means your password will be locally discarded. Should the password change or should you have signed out and want to sign back in, you will be queried to enter your password.
The Statistics
… and when signed out.This release addresses more than 50 issues (features, enhancements, bugs), so this tour is by no means complete.
We hope you like the new client, and we appreciate your feedback. Please head over to the issue tracker to tell us about bugs or regressions.
Only slightly more than a month has passed since the release of ownCloud 1.3.0 and it’s been quite a ride. But now, we are at the first milestone of the 1.4.0 release that we would like to share with you: Beta 1. The focus in this release, apart from the usual fixes, was to provide improved user feedback, and to extend both the user interface and the backend in a way that would allow us to bring the client forward. For the UI, this meant the introduction of a Settings dialog. For the backend, it meant a lot of refactoring.
Feedback
All important information is now available in the context menu.
Previous versions of the ownCloud client were quite sparse in terms of feedback. You would have to wait for a complete sync to finish in order to receive your results, and to understand what the client actually did, you would have to resort to running with the --logwindow option. No more! The new beta features feedback about the current sync progress and already processed items in the context menu. If this is not enough, you can choose Details... from the Recent Changes. This will pop up a dialog that will give you the complete details about all uploaded, downloaded, deleted and moved files and directories. On top, the information will be available as it the sync happens, but only as a result afterwards like before. There is also feedback on the upload progress both in the context menu and in the account details. When there are problems with the sync like running out of quota, the system tray icon will now change to indicate a problem.
Finally, we introduced a Help... item, which points to the official online manual. We are currently updating it to make it more useful, but it already
contains many important hints for trouble shooting. If you want to help out with documentation, check Issue #788.
Settings
Icons going native
It’s hardly believable, but so far the Client went without a settings dialog. Under the hood, we had features piling up such as switching to native/monochrome icons, but they were only available as command line switches. Now they are all pretty check boxes. On top, there are now options to disable pop ups resulting from syncs, as well as auto-starting the Client on all o systems on a per-user basis. Auto start is now only default if an account has been successfully configured.
This release features the most changes in terms of lines of code since the beginning of the Client development. Code has been refactored to enable new functionality, such as bandwidth control, aforementioned quota visualization, or to allow for Custom Ignore patterns. Not only can you add new file patterns that will be ignored by the client, but you can also define them as discardable. For instance locally created meta-files such as .DS_Store (Mac) or Thumbs.db (Windows) would not be deleted which the folder was removed remotely, rendering the client incapable of removing the directory. Ignored files marked as discardable will now be removed without warning, making the sync experience a lot smoother.
Another, still ongoing effort is the introduction of a smarter scheduler that ensures that sync runs will only be performed whenever there are changes on the server. Before, we could only detect local changes. In order to achieve this, we leverage the E-Tag, a Unique ID provided by the ownCloud WebDAV server. This should result in significantly reduced CPU load and networking traffic. No more sync runs every 30 seconds. Instead, the root E-Tags on the server are being checked, and a sync run is only started if they changed. Also, we have lowered the thread priority for the actual sync run to provide a smoother experience.
There are a lot more changes in this release, which are summarized in the ChangeLogs for Mirall and OCSync as well as the open and closed issues for the 1.4 milestone in GitHub.
We are looking for projects that would like to present in the exhibition area, as well as interesting talks or workshops. Additionally, you can request a project room if you want to sit together to do some hacking, or have your own, topic specific course of lectures. Sign up now!
But even more so, we are looking for speakers. The focus this year is on Seamless Computing, How Free Software should deal with closed ecosystems and How to let the computer do your chores. Even if your topic is not in one of those domains: Submit your proposal.
Today, along with the server updates, we have released ownCloud Client 1.2.3. This release will continue working users of the 4.5 series. Clearly the most important and single-most annoying bug this release addresses is the creation of illegitimate conflict files. This can happen due to several reasons. Lately, it has been reported due to a regression in 5.0.0 (which was fixed in 5.0.3). We now compare the files for equality, which avoids illegitimate conflict files on the client side.
We also fixed the sync handling of Microsoft Office Documents and possibly other locked files on Windows: Before, when a file was locked (e.g. by an Office application), the client would think that the file was gone, deleting it from the server (and hence other clients) until the application would release the file again. In 1.2.2, when a file is locked, the Client simply skips it. We all ignore the lock files.
People have reported this behavior as a bug for OpenOffice files already, because they think that we should transport the lock file. However, this is wrong: Suppose you sync while someone else has a lock on the file and then you go on the train: You will not be able to open the file due to the lock file. Also, by the time the lock file is synced, the original author might already have closed down the Application that was locking it. This is a matter of principle: unlike on a local file system, two people editing the same file is perfectly ok — it will result in a legitimate conflict during sync, and only on one of the sides.
Finally, a quick tour through the additional changes: We fixed some of the crashes seen especially on Mac OS when setting up a folder. Also, Linux users using Nautilus will now have their sync folder will be automatically added to Nautilus during sync setup. Finally, the Client now works with screen readers on Windows. For those observing crashes after some time on Linux, please read this post for a description of workarounds.
The packages are available at the usual place and pose a significant improvement over 1.2.1 for many users, especially when using a 5.0 server (which you should also upgrade). For the next release, we are working on chunked syncing, and an overhaul of the user interface, which also brings a lot of code improvements along the way. Stay tuned.
We had many reports on crashes due to exhaustion of file descriptors on Linux. When we started to look into them, we found that unfortunately they all have their cause in broken packages further down the dependency chain:
One confirmed leak is due to a bug in libgnutls/libgcrypt, which is not unload-safe and keeps opening /dev/random at every sync run. I added a workaround for this in 1.2.1, but that will only work if you have the unversioned .so files installed. Those are part of your distributions libgnutls-devel package.
The other leak we observed, which leaks sockets, has not finally be investigated, but seems to be related to gnome-keyring’s pkcs#11 support. Moving away /etc/pkcs11/modules/gnome-keyring-module works around the issue. We are on working proper fixes and/or getting in touch with the original authors and distro package maintainers.
I will update this post with more findings as they appear.
The ownCloud community has long suffered from a gap between users and developers:
Throughout the recent months (and particularly: weeks), people have asked me how to properly secure their SSL/TLS communication, particularly on web servers. At the same time I’ve started to look for good literature on SSL/TLS. I noticed that many of the “guides” on how to do a good SSL/TLS setup are actually 
Another issue we addressed was our new handling of files that are on the local ignore list or which contain characters that cannot be replicated to other operating systems (which is an 
Icons going native
