As long as Dynamic Configuration is locked behind an nginx plus-only API, these are hollow words.
This is a must have feature for todays workloads (kubernetes or just very busy webservers) in production, and nginx will likely continue to lose market share to Envoy based alternatives where everything is configured through APIs, without needing to reload the server.
This is definitely addressed in the article. The relevant bits talk about moving features from the commercial version to the open source version, as well as the introduction of an open source nginx agent that can do the "dynamic config" on your behalf (via API I presume).
I agree with your sentiment though! I hope they do follow through as nginx is generally an easy sell to others when trying to fill holes in your tech stack and otherwise pretty bulletproof.
Some additional context to what I'm referring, in this old blog post from 2015, nginx describe exactly why the dynamic configuration feature is important, and what's wrong with just reloading (draining the old process of connections).
https://www.nginx.com/blog/using-nginx-plus-to-reduce-the-fr...
For rolling deployments, it can cause repeated configuration changes exacerbating the problem, some workloads more affected from this than others of course. The nginx ingress controller makes this clear
> Every time the number of pods of services you expose via an Ingress resource changes, the Ingress Controller updates the configuration of the load balancer to reflect those changes. For NGINX, the configuration file must be changed and the configuration subsequently reloaded. For NGINX Plus, the dynamic reconfiguration is utilized, which allows NGINX Plus to be updated on-the-fly without reloading the configuration. This prevents increase of memory usage during reloads, especially with a high volume of client requests, as well as increased memory usage when load balancing applications with long-lived connections (WebSocket, applications with file uploading/downloading or streaming).
Just to make things interesting, there’s actually two Ingress controllers based on NGINX, one led by the NGINX company and one under Kubernetes organisation. The Kubernetes-led controller ‘ingress-nginx’ is substantially enhanced with OpenResty integration and doesn’t have the issue with reloads that the blog refers to.
You can use a switch to start the nginx process and tell it to stop accepting new connections on the old one without killing it. Forgot the switch but its in the docs. Don’t know if this is well known but this is how I made a poor mans dynamically configurable nginx like 7 years ago using the free version. It worked great
I think this is known, and the Kubernetes Ingress Controller leverages this, however you are leaving that other process behind until connections drain. If you are changing configurations often enough, you might have many old processes lying around, consuming resources and using old settings. So it's not ideal.
> Once the master process receives the signal to reload configuration, it checks the syntax validity of the new configuration file and tries to apply the configuration provided in it. If this is a success, the master process starts new worker processes and sends messages to old worker processes, requesting them to shut down. Otherwise, the master process rolls back the changes and continues to work with the old configuration. Old worker processes, receiving a command to shut down, stop accepting new connections and continue to service current requests until all such requests are serviced. After that, the old worker processes exit.
There are unsubscribe links on all their e-mails and I think the automatic unsubscribe feature too.
What I really want to know is if the OP actually tried to unsubscribe or just went directly to twitter about still receiving e-mails after cancelling his account for that nice twitter/HN buzz?
I was expecting a static binary when I downloaded the CLI, but I got a huge load of node.js files and modules. Consider packaging your node.js application up, I haven't tried it but https://github.com/nexe/nexe looks promising.
Thanks for the link. v0 cli was written in gerbil scheme (http://cons.io) but I couldn't get it to statically link on linux so I'd still have deps in the form of dynamic libs. Then I found oclif which while depending on node has a lot of what I need and will allow me to ship/iterate faster ... If the spec/features/api was fixed, I'd write the thing in golang if only for the static binaries and cross compiling but it's a relatively joyless/cumbersome language IME, so node for now at least.
I was writing a similar cli tool [1] to manage the git repositories on my own server. If you want portability, it should be fairly easy to write the cli interface in plain sh or bash, especially when most of the operations could be done on the server side. I am not sure if there is a reason to use a compiled language for this.
Title is misleading. No "hijacking" is taking place, they are obtaining the Cell ID (approximate location) and IMEI info from the phone, by sending it a malicious SMS containing SIM card instructions.
Details; https://www.adaptivemobile.com/blog/simjacker-next-generatio...
A better title IMHO;
SIM Vulnerability leads to information disclosure via malicious SMS.
Seems like a highjack may be possible actually... Here is a list of other things they listed they can do with the simjacker exploit that goes beyond simple data exfiltration:
> PLAY TONE
> SEND SHORT MESSAGE
> SET UP CALL
> SEND USSD
> SEND SS
> PROVIDE LOCAL INFORMATION
> Location Information, IMEI, Battery, Network, Language, etc
> POWER OFF CARD
> RUN AT COMMAND
> SEND DTMF COMMAND
> LAUNCH BROWSER
> OPEN CHANNEL
> CS BEARER, DATA SERVICE BEARER, LOCAL BEARER, UICC SERVER MODE, etc
> SEND DATA
> GET SERVICE INFORMATION
> SUBMIT MULTIMEDIA MESSAGE
> GEOGRAPHICAL LOCATION REQUEST
But from what I gathered from cursory search, RUN AT COMMAND isn't supported by most devices. (ETSI TS 102 223 states "This clause applies if class "b" is supported by the terminal and enabled by the subscriber through the terminal. ")
Google and Apple can't do anything to mitigate this.
Edit: The following is incorrect. SIM cards are self-contained computers. Among other things, they're responsible for encrypting and decrypting communications between your phone and your carrier. This means that a SIM card will see the contents of a message before your OS or other hardware in your phone does. These exploits should work just as well against "dumb" phones as smartphones because they're not attacking the actual phones.
This API exists because SIM cards are self-contained computers; they need a way to communicate with everything else.
That's not the case. SIM cards hold the permanent key for authentication and perform key derivation. Mobile data doesn't pass the SIM card; it does not perform the encryption and decryption.
Dumb/feature phones saved SMS messages to the SIM card as simple cards have a limited amount of memory that is dedicated to a crude phonebook and SMS store.
Smartphones and smarter feature phones (can) use their own storage for that. You could disable/enable the phonebook/save to SIM features on feature phones and early smartphones.
(I'm talking about win CE and symbian phones being early smartphones here)
VISMA e-conomic | Platform, UX, Mobile, etc | Copenhagen, Denmark | ONSITE | VISA
Do you feel motivated about making complex things simple? Do you want to demonstrate your skills in the most used cloud based accounting platform in Denmark?
Visma e-conomic resides on Christianshavn in central Copenhagen. We build and design the cloud based accounting system e-conomic.dk that helps more than 100,000 happy companies run their business. We are 170 employees from 20+ nationalities.
The development department consists of 40+ people, working with technologies like C#, Node.js, React, MS-SQL, Swift, Kotlin, MongoDB and Kubernetes.
We serve more than 50 million requests a day, push to production several times a week, love to talk about (and write) code, believe strongly in automation, and are driven by a desire to measure and monitor in order to constantly improve our product.
VISMA e-conomic | Platform, Full Stack Engineer, Machine Learning, etc | Copenhagen, Denmark | ONSITE | VISA
Do you feel motivated about making complex things simple? Do you want to demonstrate your skills in the most used cloud based accounting platform in Denmark?
Visma e-conomic resides on Christianshavn in central Copenhagen. We build and design the cloud based accounting system e-conomic.dk that helps more than 100,000 happy companies run their business. We are 170 employees from 20+ nationalities.
The development department consists of 40+ people, working with technologies like C#, Node.js, React, MS-SQL, Swift, MongoDB and Kubernetes.
We serve more than 50 million requests a day, push to production several times a week, love to talk about (and write) code, believe strongly in automation, and are driven by a desire to measure and monitor in order to constantly improve our product.
It's also a kinda crappy alternative, because it's not possible on a large number of non-English keyboard. Ctrl+c is also an option, although I think there's a slight difference.
ESC is 0x1B, traditionally the CTRL key reset the two highest bit of the ASCII code, [ is 0x5B, if you reset the two highest bits of 0x5B you get 0x1B which is why ESC and CTRL-[ are the same thing.
I wonder how many vim users have tried using CTRL + [ for the first time today. Muscle memory being what it is I fully expect that nobody will swap over to this new and improved Apple way of pressing the Escape key.
And vi too - works just fine, but you have a valid point about muscle memory, which is pretty much the only kind of memory many of us have left when it comes to vi-like editors, since the key sequences disappeared from our brains decades ago!
This is a must have feature for todays workloads (kubernetes or just very busy webservers) in production, and nginx will likely continue to lose market share to Envoy based alternatives where everything is configured through APIs, without needing to reload the server.