I am interested in seeing how the rewrite affects end-users. Currently, it seems to be mainly focused on File Sync and I don't see things such as calendar or contacts management. (they totally could appear in the future though)
I'd assume that limiting the scope of components, makes a rewrite also easier. Nextcloud for example has a ton of hooks that allow you to write apps to customize the behaviour (want users to sign the ToS before downloading a share? Should be doable etc.). When you leave these out, implementing new things just got a whole lot easier :)
(so I guess I am envious on the fact that they got rid of a ton of backwards compatible APIs to maintain :-) )
Disclaimer: Contributed to ownCloud for a few years, then to Nextcloud.
Lukas! Yep, for now, we focus on file sync and share.
Personally, I am looking into kopano or etesync to replace calendar and contacts. We already embed kopano konnectd as the OpenID provider so, there are synergies.
We do maintain backwards compatibility for the WebDAV, OCS and OCM apis and the clients are all working. The inner hook system of oc 10 obviously is gone, just as well as the internal PHP APIs. Instead we now rely on the CS3 APIs that describe a set of services in a microservice architecture to extend or customize functionality. Something that has always been fragile, because a bug in an oc/nc app could affect all other services.
Furthermore, we did not have to start from scratch but contributed to reva, which has been powering CernBox for a few years. It is the reference implementation for the CS3 api.
So, we are very much Protocol driven, which makes changing the implementation language possible if needed. And everyone is free to implement his own service replacement if he needs to. The extensive acceptance testsuite will tell you what is not working compared to oc 10 or ocis. For now, we are pretty happy with go and the initial benchmarks.
One more thing regarding core developers having moved from oc to nc. The server is just one piece of the puzzle. None, literally, none of the desktop, iOS or Android developers paid by ownCloud moved to the fork. It feels as if they were not even considered important. The sync protocol and the end user experience on his daily driver really is what matters. I am very happy that we as ownCloud finally grabbed the chance to really tackle the file sync and share part with the right tools for the job. Without being pulled in a gazillion of directions. I cannot express my gratitude for the rest of the oc sales and support team that keeps oc 10 well running and bought us the time to actually make this step. Truly exciting times
Keep in mind this is still tech preview. There is still a lot of work to do. Helping hands welcome. And yes we need to work on our communication skills...
Full disclosure: oc employee no 7 and ocis tech lead here. Originally hired to work on full text search in ownCloud 10. Good old times. Cheers to all the oc and nc devs: it should be possible to implement the internal PHP API of oc/nc using roadrunner. That might allow existing PHP apps to be wrapped in a dedicated microservice. But that is not something we are investing time in. Feel free to ping me on https://talk.owncloud.com
Are you looking into leveraging Syncthing for filesync? I always had the experience that, even recently, it was more reliable and faster. Its also written in Go.
No, but thx for the pointer. AFAICT the difference in the sync protocol is a block (syncthing) vs file based (owncloud) protocol. There are several reasons why we prefer the file based protocol.
Currently, all our clients sync using webdav. Changing the protocol would require rewriting that part of every client.
Another reason is that ownCloud as well as ocis are used to access files that resides in other existing storages, eg. S3 or CEPH. Translating those protocols to a file based sync is a lot easier than adapting syncthing (just my gut feeling).
Another aspect is that the file based sync is also state based. We can use the etag to detect changes and immediately start syncing in a breadth first approach. We are not doing that, yet. But the windows cloud vfs we implemented for the desktop clients makes this one of the next steps.
The sync in ownCloud feels slow because the clients are polling. There is currently no persistent connection that the server could use to push changes. But to be honest we have been bitten by firewalls between server and client so often that I doubt we can do real push notifications. Which is why I personally am aiming for long polling. For mobile devices we have to rely on the existing notification infrastructure from Google and apple anyway. Anyway, there are ways to speed up sync. Which switching to go made a lot more implementable. But one step after another.
We already implemented TUS for uploading files in ocis and all clients. It is a well designed extendable upload protocol that covers a lot of corner cases we have experienced first hand with all our clients. We contributed our experiences and are planning a batch extension that we would use to group lots of small files in a single upload. Delta sync should be a TUS extension as well, IMO. But that is mostly in my head.
First, we want to get the basic file sync and share features fully implemented.
So ... Yeah ... Changing the language and the architecture kind of made a knot disappear and we are moving forward.
In that regard, I personally have an eye on the Microsoft graph api which we could use for file management. Input welcome.
> Plus as far as I know neither ownCloud nor nextCloud went through a security audit
This is inaccurate. Nextcloud does receive security audits and is in fact also used by quite some security-conscious organizations (to name a few: German Government, Siemens, ...)
There's also a bug bounty program that pays pretty decently considering the company size: https://hackerone.com/nextcloud. (Remote Code Execution = 10k, Auth Bypass = 4k - compare that to rewards that the FAANG pays and you'll see it's not that bad)
> and they are big piles of PHP with a lot more complexity than Seafile
I did a small audit of Seafile years ago and I don't think that argument flies.
```
def random_string():
"""
Generate a random string (currently a random number as a string)
"""
return str(random.randint(0,100000))
```
That's not really secure and copy-pasting Django core code and then removing security checks ... is shady at best.
Disclaimer: I wrote a significant part of the ownCloud code (https://github.com/owncloud/core/graphs/contributors), then forked it into Nextcloud. After some years I moved to Facebook to do application security there :-)
Oh wow, thanks for the quick reply. I searched for nextcloud audit but haven't found the reports, just docs about the "monitoring and audit" and the "security scan" feature. (I still can't, but maybe that's because these audits/reports are not public, I don't doubt your word.)
I've been working on an open-source Identity Access Management solution in the past few months: https://gatekeeper.page/en/
Gatekeeper aims to enable small and medium-sized enterprises to have their own on-premise IAM solution that supports all relevant protocols and standards and is secure by default (by offering automated updates and using memory-safe languages etc.).
Features include, for example, LDAP, OpenID Connect, SCIM, and Gatekeeper as an identity-aware reverse proxy. (with fully managed ACME certificate management)
The tech stack is ASP.NET Core + Postgres on the backend. The frontend is written in C# and uses Blazor to run using Web Assembly. If someone is interested in taking a look, we are working on a hopefully helpful Developer Documentation (https://docs.gatekeeper.page/developer/)
How else would you phrase someone telling you "I have this bug and will exploit it if you don't pay me X amount" vs. "I think the impact is bigger because of Y"? For me, the first sounds quite clearly like extortion.
The first case would get you likely in trouble. The second case would routinely cause a further review in any decent program, and if there's any merit to it, you get a higher bounty.
Nobody is forced to participate in any bug bounty program. If people feel the reward is too low, they should not partake.
I'd advise anyone against trying that for a system not owned by them. (e.g., someone's else website)
As soon as you do that, you venture into dangerous territory. Companies are required to investigate claims of breaches seriously. And as soon as something like this is escalated, it may be out of the Information Security team's hands to decide the next steps.
I was part of "big corp" for the past three years and was involved in many bug bounty reports. A reasonable claim like "I think this should be higher because XYZ" gets investigated and, if justified, higher bounties issued.
This blog post seems a bit one-sided and doesn't correlate to the facts that I have heard. I wasn't there at the time being so I don't know the truth. But that blog post seems not quite 100% to be it.
What I have seen, however, in the past years, is that some people omit facts or misrepresent things to get some press. So I am quite a cynic on blog posts like this :-)
> A reasonable claim like "I think this should be higher because XYZ" gets investigated and, if justified, higher bounties issued.
That's highly dependent on the individuals and the company doing the bounty. It's incredibly reasonable that people are suspicious of the process, when it is opaque as it is, and the disparity in negotiating power being the company and the person submitting the bug.
My personal experience is the FB bug bounty process has been generally positive, but inconsistent at times in the graded severity of issues and transparency of the decisions being made. I've clearly presented my case, and asked for additional information, but not gotten very far. My only real option in response is in how I allocate my time.
Having reports and payout amounts be permanently hidden results in stories like this being the only insight to the process.
Well, it includes verbatim copies of the whole email chain, and those are looking pretty bad in itself without any of the surrounding text.
Unless you're saying they've been tampered with, or that there was additional communication in between that he omitted, it seems pretty clear that this is not a professional way to handle communications.
Disclaimer: I was a Security Engineer on the FB Security Team until last month and was also involved in the Bug Bounty Program :-)
That's not how Facebook treats Bug Bounty Participants. By far, it's one of the better programs in terms of payouts, fairness, and triage time on critical issues.
Just a recent example: a bug bounty hunter reported unexpired CDN links. After internal research, FB figured out to chain this into a Remote Code Execution and paid out 80k USD to the researcher. (https://www.facebook.com/BugBounty/posts/approaching-the-10t...)
That said, I wasn't there in 2015, so I only know the story from some stories. (which portray the story a tad different) - Even if it were true, I haven't seen such treatment in the last three years at FB.
Forgive us (non-facebook engineers) if we don't take your (single rank-n-file engineer) anecdotal experience for official company policy when there's a public documented case of the head of the department doing otherwise.
Based on FB's official rebuttal, he had mentioned his company affiliation on the bug bounty portal account and had used a company email address for the communications. To me, this indicates that he was acting in an official company capacity.
Further, they didn't reach out to the CEO of the company until after he'd exfil'd data from the IG S3 bucket outside the scope of the bug report to try and leverage a bigger payout.
I have no reason to doubt any of that.
There's a lot of negatives about working at Facebook, but a lack of professionalism is not one of them.
I think FB's greatest achievements is convincing their employees that their jobs are actually good for society, or at least neutral. Plenty of good people working there who seem honestly confused about how their jobs lead to so corruption and downfall of our society.
Upton Sinclair got this right almost 100 years ago- “It is difficult to get a man to understand something, when his [RSUs depend] on his not understanding it.”
Of course, I also work at a FAANG, so people in glass houses and all that...
Their culture of continuous (and I do mean continuous) performance review ensures they're always focused on not losing their jobs. If you know someone who works there, ask 'em.
> Companies always say they will investigate the full impact of a vulnerability when you follow the protocol they urge of "as soon as you find something, report it and don't try to escalate". But this is nearly impossible to do even if you're trying in good faith.
Disclaimer: I was a Security Engineer on the FB Security Team until last month and regularly attended the payout meetings :-)
I've seen plenty of bug bounty programs making such claims, but the Facebook program keeps up to this promise the most. Every bug is root caused to the line that caused the issue and assessed on maximal potential impact.
Sometimes that leads to cases where low impact vulnerabilities got paid out tens of thousands of dollars. The big bounty often came as a big surprise to the reporter :-)
So what do you think is going on in this piece (5 years old), where Alex Stamos characterizes the issue as "trivial and of little value"?
> Facebook has big pockets. As a bug bounty hunter, I'd not worry about being screwed by them. It's by far one of the best paying bounty programs.
I don't think the middle sentence is related to the other two. Every company I triaged for had deep pockets. I routinely saw payouts in excess of $1,000 and not uncommonly several thousand. I don't recall ever seeing one that hit $10,000. But what I'm describing above are ways for the company to screw the researcher without really being motivated by stinginess. Fairness is not a concern.
> So what do you think is going on in this piece (5 years old), where Alex Stamos characterizes the issue as "trivial and of little value"?
I sadly wasn't there at the time, and Stamos post doesn't refer to it at all. So I can't comment on this.
I guess the truth on this is just known to the researcher, their boss, and Stamos.
> But what I'm describing above are ways for the company to screw the researcher without really being motivated by stinginess. Fairness is not a concern.
That's a fair point, and I can see how representation can cause a significantly different payout decision, especially if there is no technical payout panel with a security background.
Phrasing something as "Reflected XSS" vs. "Account Take-Over via XSS" sounds undoubtedly different. But it is impact-wise probably the same.
The problem is mitigated at Facebook by having engineers in the payout panel that understand the tech stack and security implications. But I think many companies don't have that luxury, and you undoubtedly may end up with inconsistencies.
Thanks for sharing your perspective. Much appreciated!
Fair enough, there is some kind of marketing-ishy statement in that. I give you that :-)
But considering the security features that we include such as Same-Site Cookies, CSP using Nonces, etc. I don't think the statement is totally wrong – many products are sadly missing these. We also have a bug bounty program where we offer up to $5000 for qualifying vulnerabilities: https://hackerone.com/nextcloud
Probably the easiest way in your case is to backup the config folder and your data folder, then uninstall the ownCloud packages and install PHP/Apache yourself. Then simply put our newest release into the web root and copy your old config there as well. If you need more help on that I'm sure we have many people in our forums willing to help :)
