eeZi

This is precisely why we need projects like Grsecurity.

German equivalent, must read if you're a climber and know the language: http://www.bergundsteigen.at/

Austria, Switzerland and Germany have a very long rock climbing history (unsurprisingly), and their respective climbing associations are obsessed about safety.

Different story, then.

But YubiKeys are built on a hardened hardware security module instead of a general purpose phone operating system with full network connectivity and a huge attack surface.

Having a UI does not increase security in a meaningful way. The attacker is just going to wait until the victim connects to an interesting target server and then hijack that connection. The ControlMaster feature makes that trivially easy, but it's not hard to do real injection [1].

If the workstation is compromised, it's over.

At that point, all you can do is to prevent an attacker from copying the key or using it without user interaction. A YubiKey does both - you can optionally set it to a mode where you have to approve each signature.

With a bank transaction, the whole transaction is part of the approval process and can be verified out-of-band. With a SSH login, this is not possible since you're still going to trust the workstation as soon as the session is established.

I'm not saying this project is useless - IF your phone is actually more secure than your workstation - which may or may not be the case - AND you've been previously been storing your keys on your workstation, then it's definitely a step up. But really, at that point, just buy a YubiKey (and properly secure your workstation!).

Otherwise, you now have TWO single points of failure instead of one. If either your phone or your laptop is compromised, it's over.

If you want login approvals that show the server name, do it as a second factor and use something like Duo Security with push approvals. This actually increases your security - instead of having, an attacker would now have to compromise both of your devices.

[1] https://github.com/seastorm/PuttyRider

You don't need either Kubernetes or OpenShift if all you need is 2-3 instances. Just write an Ansible playbook.

That being said, I do run a few 2-3 node OpenShift clusters and the additional complexity was well worth it.

For anyone interested in Kubernetes: Red Hat's OpenShift is worth taking a look at.

It's upstream Kubernetes + a PaaS framework built in top of it.

It takes care of role-based access control, has a secured Docker registry (prevents applications from pulling each other's source code), Jenkins integration and can automatically build, push and deploy your applications.

Our team started using it and it's great. The documentation is top-notch (it's probably the best docs I've ever seen in an open source project).

I've seen many teams re-invent the wheel over and over again, when OpenShift already does most of what they need.

Happy to answer questions!

https://www.openshift.org/ (`oc cluster up` and a running Docker is all it takes for a first test)

Docs: https://docs.openshift.org/latest/welcome/index.html

Blog: https://blog.openshift.com/

It resulted in random, hard to reproduce ENOSPC errors down the line without either data or metadata being anywhere close to full. Neither us nor the btrfs developers that took a look at it were able to figure out what exactly went wrong, but it was something about new blocks not fitting anywhere despite lots of free space.

Someone on #btrfs said that the filesystem layout is a lot different when using the conversion tool and all of the regression testing happens with regular filesystems, not converted ones.

We reinstalled all machines from scratch. Never happened again.

Streaming means parsing a bunch of untrusted data. What if ffmpeg/gstreamer/Clementine has a security issue? It happened before.

With a Chrome App, it sits in a (really strong) sandbox and would need to escape the sandbox first.

With a native app, it's game over.

Red Hat is trying to address this with their Debezium project:

http://debezium.io/

JetBrains DataGrip comes close and supports many different SQL dialects (it's also comes with IntelliJ as the SQL plugin).

You can do that with regular web apps - just create a desktop shortcut in the Chrome menu ("More").

Signal Desktop and Cleanflight are open source.

And sometimes, you have no choice - there's no FOSS alternative to TeamViewer, and thanks to it running inside Chrome, I no longer have to run a Windows VM.

The web based SSH client is published by Google themselves and they use it internally.

The teams working on Debian, Ubuntu, Arch, etc. have much better security track records than some random web developers who've made an "app".

The way things are, right now, Chrome is much better at protecting apps from each other than my Linux desktop is. If, for example, the Cleanflight or TeamViewer apps were regular apps, a bug in them would fully compromise my account.

---

Off topic remark about Linux distro security: I really like Arch, but security isn't their strongest suit. For example, they still haven't enabled full-system ASLR, citing unfounded performance concerns, when other distributions did so years ago. Even Windows with all their third party apps has a higher percentage of ASLR binaries than the average Arch system.

They also have no central build system and instead rely on volunteers who build the packages on their personal systems and sign them using their personal GPG keys.

I really want ASLR in Arch so I'll keep complaining about it publicly until it finally happens :-)

Hah, that's a funny thread. I've heard that Google is using Chromebooks for engineers with production access.

Makes a lot of sense sense since Chrome OS is much easier to secure than a normal Linux distribution.

But that's only Chrome OS.

Chrome Apps were great because they worked on all (desktop) platforms.

Agreed, the SSH client is a bit of an outlier since you have that natively.

I still listed it for completeness, I do use it, after all.

Chrome OS has no native SSH client, but Google published a NaCL based SSH client:

https://chrome.google.com/webstore/detail/secure-shell/pnhec...

It's useful outside of Chrome OS if you have a security perimeter based on TLS with ACLs and auditing already in place and you want to use it for SSH as well:

https://github.com/zyclonite/nassh-relay

https://chromium.googlesource.com/chromiumos/platform/assets...

Google uses a similar setup internally.

I'm running btrfs in production with a very heavy workload with millions of files and all sorts of different access patterns. Regular deduplication runs, too. We're probably one of the largest btrfs users.

Had a LOT of unplanned downtime due to various issues with older kernel versions, but 4.10+ has been solid so far. You definitely need operational tooling (monitoring, maintenance like balance) and a good understanding of the internals (what happens when you run our of metadata space etc.).

Happy to answer questions!

On a related note: Never ever use the ext4 to btrfs conversion tool! It's horribly broken and causes issues weeks later.

This one I'm fine with since WebAssembly is a worthy replacement, but I'm still annoyed at Google discontinuing Chrome Apps.

Some examples of specialized apps I use all the time that would require a native app otherwise:

- Signal Desktop

- TeamViewer

- Postman

- SSH client

- Cleanflight drone configuration tool

It was one of the best things that happened to Linux desktops in a long time and removing it hurts users and makes them less secure.

Now everyone is moving to Electron and instead of one Chrome instance, I'm now running five which use more than one GB of RAM each. Much less secure, too, since each has its own auto-updater or repository and instead of being sandboxed by Chrome's sandbox, they're all running with full permissions.

It also means I cannot longer use Signal Desktop on my work device since installing native apps is forbidden for good reasons, while Chrome Apps are okay.

It also hurts Chrome OS users since Chrome Apps are being abandoned in favor of Electron. It also makes it less useful for developers to create Chrome Apps since the market is much smaller.

Since Chrome Apps continue to be available on Chrome OS, I'm considering separating that functionality into a stand-alone runtime or making a custom build for Linux. Anyone wants to help with that?

Can anyone recommend this?

https://github.com/bitly/oauth2_proxy

Now that's it's open source, it should be easy to fix it.

Facebook in Germany doesn't have those alt tags.

Google Trends chart:

https://www.google.com/trends/explore?date=all&q=python%203

Can confirm. Ported our internal stuff and it was much easier and faster than expected.

Lots of incentives for us:

- clean Unicode support which prevents mistakes which used to bite us in production

- native async syntax, compatible with Tornado

- asynchronous generators (yield from a coroutine!)

- pathlib and os.scandir

- type annotations

- matrix multiplication

- chained exceptions

- faster dicts, ordered by default

So many useful features, and with the latest Python 3 releases porting has become really easy thanks to improved compatibility with the old syntax.

For Ansible, it's important to differentiate between the master and client side code.

Client side code has to run on everything starting with CentOS 6, so they have to stick with Python 2 for a long time.

For the Ansible master (which runs on the management machine), Python 3 porting work is already underway.

Same here.

Haven't had a single Unicode bug in production since we switched to Python 3. Also, chained exceptions (extremely valuable in walled-off production environment).

Type annotations actually work and have prevented a number of bugs.

The asyncio syntax is really nice with Tornado (don't use aiohtto, use Tornado! it's much more mature)

All major distributions have completed their switch to Python 3 or ship it already.

This is Canonical's stance:

All Ubuntu/Canonical driven development should be targeting Python 3 right now, and all new code should be Python 3-only.

Regardless, nowadays many people deploy Python applications as stand-alone bundles. We're happily running Python 3.5 on CentOS 6 and it took like ten minutes to deploy (pyenv!). This lets us use a rock-solid base system with an up-to-date application stack, which makes our old school admins happy.

It's also the case that Debian accepts binary packages built on the developer's personal machine

Pretty common - many community distros do. Arch Linux too. Worrying for obvious reasons.

At least they're putting in an actual effort at making builds reproducible.

Irrelevant - it's way beyond repair.

Doesn't mean we shouldn't try, since we're not getting rid of if anytime soon.

Google's Certificate Transparency is a great approach.

WhatsApp messed it up particularly bad, but it's not the only example. The point is that there was no private access to the SD card. If you had large files that did not fit on the internal storage, using the shared external storage was the only alternative. Developers abused that and ended up putting all sorts of private data on the SD card.