erhardm's comments

I think that's the Kerckhoffs' principle[0].

Regarding to state actors who have the resources to attack any system, I think it's important to make it as hard as possible, even if it's "known" they will find a way. Why?

Because it will drive the costs very high with years of R&D having as result that they'll only use new attack techniques on high-level targets and that means risk of revealing attacks goes up(assuming high-level targets are more sophisticated and spill the beans - as in Kaspersky case[1]).

[0] - https://en.wikipedia.org/wiki/Kerckhoffs%27_principle

[1] - https://securelist.com/blog/research/70504/the-mystery-of-du...

Welcome to the new world of closed ecosystems. May be a wakeup call for others who think they can directly compete with those who actually pull the strings of the ecosystem.

When the TA from my university told us updates for the laboratory will be on facebook, I told him I want them on email. Everyone in the room looked at me like I was a dinosaur who doesn't have a facebook account.

TA was surprised too as well, until I asked rhetorically "why facebook? Why not Google+, LinkedIn, Twitter, Snapchat, Kik, DropBox etc?". The TA then understood my point and updates were sent on email.

Although Meerkat vs Periscope is not exactly the same thing, but its problems are from the same reasons, open vs closed ecosystem.

I like OpenBSD. I like the spirit of the developers, which don't compromise on security. I like the simplicity of the OS, very good documented and very robust. They are prepared to break a ton of software to advance the state of security/correct code.

I would like to have OpenBSD on all my machines, but unfortunately their license don't have the "infectious" effect of GPL. From my limited understanding, their license[0] is not a philosophical license like GPL. Linux popularity spread because of the distributed development style(everyone developed in their own tree, Linus decided if it had enough value to get in his tree) and GPL.

Even if you don't care on the philosophy of GPL, you can't deny that it helped make a lot of vendors to publish(even if half-hearted) their code which eventually after some cleanup(3rd party or themselves) got into the Linus tree.

If OpenBSD would be GPL licensed, I could see a BSD which would be have all the bleeding edge features, but Theo's tree was separate, conservative on features but not lacking on drivers. Men can only dream.

I realize that FreeBSD is the bleeding edge of BSD land and I'm not trying to start a license flamewar, but a lot of companies, i.e. graphics, wireless cards, laptop manufactures don't have (good) working drivers for BSD land, at least not published code which goes back to the community.

[0] - http://cvsweb.openbsd.org/cgi-bin/cvsweb/src/share/misc/lice...

Doesn't matter. The condition will short-circuit at murder:)

@ghostly_s

I don't see this as the roadblock. They (the experts) could bill by the hour. The most intensive period is the initial specification/design/architecture. After the burst period they just have to review the commits for security pitfalls and merge them if OK. The community could have some volunteer reviewers for triage.

I have no idea if this actually works and I also didn't heard anything like this done before, so take it with a grain of salt. That's why I asked more knowledgeable people how feasible this could be.

If only the design/architecture would be contracted to experts and the actual implementation be written by the community how expensive would that be?

The experts shouldn't write any line of code, use the community as code monkeys, only accepting pull requests and merge them in the project(basically what Linus does this days). Would that not be feasible?

OpenSSL is not the work of the OpenBSD team. They work on LibreSSL[0] which is a fork of OpenSSL.

[0] http://www.libressl.org/

Probably because it's not from the U.S. I encountered a lot of startup descriptions like european based startup, german/berlin startup, etc. The place isn't that important, but some think that it's mention worthy if it's not from a startup cluster.

PHP hammer[0] made using the specification[1]

[0]https://secure.flickr.com/photos/raindrift/sets/721576294929... [1]http://eev.ee/blog/2012/04/09/php-a-fractal-of-bad-design/#a...

A good developer uses the best tools available, because she/he knows the value of using them.

Replying with a CVE is like icing on the cake. :) It really shows that OpenBSD devs take security seriously. Funny timing, I was just reading Absolute OpenBSD.

You mean the article or the feature? The article is dated by 22/11/2014. The feature may have been added a few months/years ago, but the point still stands about systemd showing signs of feature creep. Note also the DNS resolver issue[0]

[0] - http://seclists.org/oss-sec/2014/q4/592

Systemd is starting to show the signs of feature creep which IMHO is good. Failing early means the ship can be turned around if there's enough will, or at least (newer) replacements of systemd(in case it goes really off the rails) will learn from others' experience.

Totally agree. It's mind blowing to realize that because of the init system we have on our system we are now vulnerable to DNS poisoning.

Do one thing and do it well.

Others working on systemd shims out of necessity is a sign, IMHO, that systemd is in reality a hard dependency in the near future (and developers trying to free from that dependency). I don't say systemd is not useful, GNOME using it shows also to good sides of it, but others feeling a little forced to choose systemd or The Unix Way I think is the wrong way to do it. Why can't we have both(modern init system and unix philosophy)? Not possible? Not enough interest/resources?

TBH, I currently feel the same way because of the opt-out, not opt-in situation. On one machine running Debian Sid I just found myself running systemd after an dist-upgrade..blowing my mind considering that I didn't choose Arch in the first place for the rolling release machine because of the systemd. But GNOME3 is to blame making systemd a hard dependency(Even if they mostly seem to be from the same camp, RH).

They're good points, but from the philosophical point The Unix Way, systemd leaves some things to desire. Is there a modern Unix way? I don't see a lot of exploring in this area/side, but I see a lot of this is the way it's gonna be from now on on the other side.

I'm not on either side, but I appreciate the way some complexity is dealt with simple little things. So elegantly solving problems: https://www.youtube.com/watch?v=S0mviKhVmBI#t=450

At least one of each side of the debate. Preferable there should be two, one on each side which implements the good/novel ideas and others where aggressive experimentation takes part.

I see the whole pro/anti systemd as a philosophical debate. Basically each part is arguing where the complexity should be in the system and how dense it should be distributed. I think we need two competing init systems to really know maybe in 5-10 years what the best trade-offs are. A modern sys V init and systemd.

Maybe today they're not incriminating, but tomorrow they will be. Better safe than sorry, but you still want to live a "fairly normal" life.