LukasReschke's comments

Earlier discussion from yesterday: https://news.ycombinator.com/item?id=25869798

> Most rewrites fails because the team rewriting is not the team that did the initial development.

Looking at https://github.com/owncloud/core/graphs/contributors, most of the initial core contributors contribute now to Nextcloud instead.

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.

> 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.

For example, they copied https://github.com/django/django/blob/23c612199a8aaef52c3c7e... to https://github.com/haiwen/seahub/blob/b6f8935c0f355cc70145f9... and removed some security-critical checks. They removed the check for the password hasht here. (https://github.com/django/django/blob/23c612199a8aaef52c3c7e...)

Furthermore, the Django secret key was generated as shown at https://github.com/haiwen/seahub/blob/b6f8935c0f355cc70145f9....

``` 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 :-)

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/)

The code on GitHub: https://github.com/GetGatekeeper/Server

> 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!

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 :-)

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.

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.

> 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 :-)

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 (https://www.facebook.com/BugBounty/posts/approaching-the-10t...)

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.

There are many reasons to criticize Facebook or Instagram. But the handling of its application security should not be in the top 10 :-)

Just as a remark, we run a bug bounty program at https://hackerone.com/nextcloud offering up to $5,000 for Remote Code Executions.

If someone here feels challenged: We look forward to your reports. :)

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

We don't offer any PPA for the server repository ourselves. Mainly because we didn't had many good experience in the past with repositories.

So what we're focusing on is providing an easy and reliable updater (just like Wordpress does) instead of distribution packages.

Migrating is described at https://nextcloud.com/migration/ and we also have a help topic in our forums: https://help.nextcloud.com/t/migrating-from-owncloud-to-next...

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 :)

> Is it the locations services workaround thing?

That's correct.

I highly doubt that the planned features are related. Seems just to be a try to make the press release look less worse...

Disclaimer: I quit ownCloud to work now at Nextcloud.

Happy to answer this. First of all: Makes using a specific programming language a software much less secure? Probably not. You can do mistakes in every programming language. But since a lot of software is written in PHP and there are also many unexperienced PHP developers this reflects kinda bad on the language.

There is often the perceiption that ownCloud would be insecure because we have so many advisories. But these are just there because we proactively look for security vulnerabilities and patch them. (see also https://statuscode.ch/2015/09/ownCloud-security-development-...)

Oh! And we also run a bug bounty program for ownCloud and Nextcloud will have one with probably even higher rewards soon! - HackerOne did even do a case study with us so it can't be too bad ;) (https://hackerone.com/resources)

Good questions! Note, that I'm affilated with Nextcloud so obviously a bit biased.

Only because a project is very transparent about security vulnerabilities does not necessarily mean it's inherently insecure. In fact, at ownCloud we found all critical vulnerabilities ourself and also run a successful bug bounty program. (for Nextcloud we are also considering one)

Check https://news.ycombinator.com/item?id=11821854 for more insights.

Not in the way that you require it. But you can always file an issue or enhancement request :-)

That said, we'll likely have Webcal support (https://github.com/owncloud/calendar/pull/443), that way you can at least in ownCloud view your Google calendars. (it's not synced though)

Actually, I should add that to my CV "poached developer" ;-)

- Lukas (Nextcloud'er - see also http://www.zdnet.com/article/owncloud-founder-forks-popular-...)

The impact is a different one though. In that scenario pointed by Hanno somebody needs to have access to the storage which already requires some kind of previous gained access. What could be done by an attacker then is to infect EXE files or so.

In the case of Seafile one could simply change passwords of any user etc.

But yes, crypto is hard and I agree that the way we did it at ownCloud is far away from the best way. :-)