masom

The issue is UFW ignoring other firewall rules, Docker just adds itself to iptables, but UFW actively ignores other chains. The bug is on UFW being insecure by design.

It would be nice if the post title would include the article title, I didn't know who was Robbie Robertson, what they did, and why it might be relevant.

https://news.ycombinator.com/newsguidelines.html

It really depends what you design your system to handle. A sudden burst of traffic that can be spread for minutes is fine (ex: Elasticsearch indexing requests can usually be delayed through background jobs).

> Basically those things only sort of work if you have few messages and are happy with millisecond latency.

Not really... queues are great to defer processing or have longer running job than your HTTP and TCP timeouts will allow. Building large data export won't happen within a single HTTP request.

ex: https://shopify.engineering/high-availability-background-job...

The reason docker is integrating this way is to easily group the rules it introduced.

> I feel Docker should have tried to play nicer with the firewall.

The problem is on the UFW side not setting up properly when other chains are present. UFW is just a front-end for iptables, and docker integrates with iptables. Can the situation be made better? Likely on the UFW side. https://docs.docker.com/network/packet-filtering-firewalls/#...

The docker behaviour is documented...

UFW seems buggy in that it only operates on set of prefixed groups instead of looking at all the groups in iptables. Now, looking at the UFW code: https://git.launchpad.net/ufw/tree/src/backend_iptables.py?h... it seems to setup it's own chains and ignores everything else. It even filters out all other chains unless they're part of UFW.

It's a bit difficult to cover as it is highly dependent on the queue system you use.

You'd usually want your queue system to fail the enqueue if it is full, and you'd want monitoring to ensure the queue isn't growing at an unsustainable rate.

It also forces you to think a bit about your message payload (rich data or foreign keys the worker loads).

RabbitMQ, Redis-based queues (ex: ActiveJob or sidekiq), Gearman, and others will all offer different mechanisms to tackle full queues.

It does not bypasses them, it uses the firewall to add forwarding rules to the container. If you read https://www.baeldung.com/linux/docker-container-published-po... there's a bunch of ways to prevent this from happening.

By enabling port forwarding and exposing, you're essentially asking docker to configure the host for it. It's likely a surprising behaviour, but seems like ufw has a bug if you have multiple chains and groups instead of just the default one.

> I don't understand how you can make queueing high-performance. Queueing things is literally the opposite of making things fast.

You likely need to read about message queues, why they are used, and why they have performance constraints. Message queues are a system, and the system to maintain those queues and content has an overhead. The project is building a solution that is higher performing than comparable systems.

Queuing things often makes things faster (!) as you are usually dealing with limited resources (ex: web and job workers) and need to operate on other systems (ex: payments) that have their own distinct capacity.

If you have 1000 web workers, and your upstream payment provider supports 10 payments per minute, you'll quickly have timeouts and other issues with 1000 web workers trying to process payments. Your site won't process anything else while waiting for the payment provider if all web workers are doing this task.

A queue will let you process 1000 web requests, and trickle 10 requests to your payment provider. At some point that queue will fill, but that's a separate issue.

Meanwhile, your 1000 web workers are free to process the next requests (ex: your homepage news feed).

Leaving your car door open isn't a great analogy.

The internet is closer to leaving your own journal open at the library or a magazine store, and people going through it. You made it available for everyone to peek at in a public space. Maybe you didn't intent to leave it there, maybe you didn't intend to make it visible, but you did.

Feels like most of those posts, and people using StackOverflow + Google search popularity, somewhat misses a few key aspects that would cause people to search.

It seems to ignore technologies not present, or lower ranking, might just have better documentation and less confusing semantics? TypeScript isn't easy to use.

GDPR isn't really related to the infrastructure, and isn't a problem if you built your product knowing you'll need to conform. Shopify is GDPR compliant, for all merchants, and runs on Google Cloud in multiple regions.

InReach, and any users (other brands offering competing two-way communicators) of the Iridium satellite network, have ongoing fees. They're rather small compared to someone dying in the wilderness.

No, the article just mentions it started as C#.

Hydro power has some high drawbacks, including being affected by droughts. They're flooding large swaths of land, destroying ecosystems, are extremely energy intensive while being built, cannot be built anywhere you'd need one, and result in large destruction when they fail.

Measuring your fridge is important as it could point to a bad compressor or bad seals.

Your fridge compressor shouldn't be running 24/7, and it should mostly be on standby until temperature rises.

> Android doesn't have anything like it either.

Uh, it sure does through the applications section. You can see running services, which ones are taking battery, and stop/disable those as well.

We use Stripe...

> This certainly makes Stripe the most valuable private startup in the world.

Stripe has not been a startup for a while, they've been in public operations for about 10 years now and probably power a large portion of online purchases.

> Shopify does not have an open API where anyone can access data given an OAuth token

We do offer a full GraphQL and REST API that can be accessed through private app keys (apps installed outside of the app store) or through the app store oauth tokens.

https://shopify.dev/docs/admin-api/rest/reference https://shopify.dev/docs/admin-api/graphql/reference https://shopify.dev/docs/admin-api/getting-started#authentic...

What would be Facebook options to stop Kogan or Cambridge Analytica?

They already have the data, other than suing, what's possible here?

That is mostly what happened. Some French company wouldn't play nice.

That's not very useful for your CEO/CTO/CFO/sales/etc when they are offsite or traveling.

> almost every basic function needs to be imported from some third party, which also feels not so safe, as a sys admin

Go (and most languages) also supports importing a lot of packages from third-parties. Just pin your dependencies to specific known versions and do hash verifications.

Thumbor let's you store and retrieve your images anywhere. We use AWS S3 with a redis storage cache + another redis cluster to store the result cache.

> Still hard to figure out which version of openssl is actually running in production

You could check the version of openssl in a specific image id and check if that image is used on the cluster.

If one of your image has a package with known security updates it is just a matter of re-building it with the newer package and re-deploying.

Seeing that PHP 5.6 is just about to be released and PHP 5.4 has been out for years, I would target php 5.4+

PHP 5.2 has reached end of life over 3 years ago. http://php.net/eol.php

* No logging

* No unit tests

Indeed. I don't quite understand the reasoning behind the license.

Please don't mix tab and spaces :( https://github.com/goldenice/Kamele-Framework/blob/master/sy...

Using proper namespaces would be great, the `System` namespace will probably collide with other projects. `Kamele\System` would be much better.

Using PDO would be much better than the `mysqli` functions.

Where are the unit tests?