711 karma · joined October 5, 2014
https://www.danieldent.com/blog/ncix-able-auctions-bowra-gro...
I've authored a similar Docker image with less features: https://github.com/DanielDent/docker-nginx-ssl-proxy
(Although lately I've been finding my cookie-or-IP-or-HTTP-basic auth feature extremely useful in development, which this doesn't seem to have from the README)
It hasn't been updated in a while, but I've also got an automatic service discovered based version of this for Rancher 1.6:
(1) Cost - IP allocation isn't close to free, either in $ or in time/administrative overhead.
(2) Technical Complexity - Using routing protocols like BGP is not currently a process with enough automated tooling to make it realistic
Those problems could likely be overcome with concerted effort.
But the biggest problem of all may be what this would do to the size of global routing tables. We've already got a problem with routing table size exploding with more and more people advertising smaller and smaller prefixes. All of that high-performance ram is expensive. That routing table is globally replicated.
If it were affordable for everyone to announce their own prefixes, routing tables would be prohibitively large. I don't think we yet have any good answers to this problem, and I am genuinely interested if you are aware of any.
There's not a chance that BGP is going to get set up or that their own IP allocation is going to happen.
How do you propose they implement multi-homing for their entire network? How do you propose they balance their link utilization?
Adding new features is great, but making sure that the user experience around existing features is smooth/sensible/not frustrating is pretty important too.
The approach of shipping 80% solutions which take 20% of the effort probably got Gitlab to where it is today. But at some point the company is large enough and has enough resources that it's reasonable to expect that the difficult parts of the problem and the "polish" get addressed too.
And it's a very good thing that their product allows you to self-host, because I have zero-confidence in their ability to properly operate infrastructure.
But the attention to detail/quality on the product itself is lacking too. Don't get me wrong, I love gitlab as a product, but they really don't seem to care about working on anything that doesn't let them check another box on a marketing feature sheet.
A selection of some issue I've filed...
Only took around a year to fix: https://gitlab.com/gitlab-org/gitlab-ce/issues/25388
Then this issue lingered for about a year before being closed because a customer filed a similar issue a couple months after I did... that other issue is still open though, so maybe they'll get around to it eventually: https://gitlab.com/gitlab-org/gitlab-ce/issues/25535
Here's one from two years ago that's still open: https://gitlab.com/gitlab-org/gitlab-ce/issues/19846
It's possible that issue is actually fixed now. I don't know and I don't care anymore.
Here another issue from 2 years ago: https://gitlab.com/gitlab-org/gitlab-ce/issues/19656
I filed that issue after a Gitlab person here on hacker news specifically invited feedback on UX/UI issues, and I had just spent a frustrating time trying to track down a runner.
At some point I just stopped filing issues & started ignoring the issues I'd already filed. The times they decided to close issues because they'd been open a long time certainly didn't inspire me to waste any more time trying to help them improve the product.
Closing & re-opening and re-tagging and doing everything but actually fixing the issue is not confidence inspiring.
Gitlab is still a great product, but now when I run into things that might warrant opening an issue, I just find ways of dealing with them on my own.
Thankfully command-line curl won't follow redirects unless you pass it a special flag, though if you do need it to follow redirects, I'm not sure what the best way is to restrict the range of redirects that it will follow.
This issue was part of a broader coordinated disclosure and was only published today. I've gotten in touch with B2 support & I'm hoping my support ticket will make it to the correct people.
It helps reduce the blast radius of a compromised server.
In the case where the server is operated by a third party (as is the case with the B2 API server), there can be many compliance implications if that third-party-operated server has access to an internal network.
We don't accept when SSH clients or web browsers have the ability to do things they shouldn't based on instructions sent by the server they connect to.
Why would we suddenly have lower expectations of our file storage API clients? (or any other network/HTTP clients for that matter)
In IPv6 land, that can introduce a lot of pointless complexity.
It would be reasonable for customers to be able to expect the ability to get /48s or /56s. Instead they don't even get a proper /64.
"v=spf1 ip4:199.185.220.0/24 ip4:198.161.157.0/24 ip4:198.161.156.0/24 ip4:204.209.205.0/26 ip4:209.171.16.0/24 ip4:100.64.0.0/24 mx ?all"
100.64.0.0/24 is within 100.64.0.0/10
Either I'm missing something, or Telus appears quite confused about the purpose/nature of SPF.
A significant portion of your observation can likely be attributed to reporting bias: it's easy/cheap for a journalist to browse the website of their local Florida police department. In another jurisdiction, that same story might involve: hiring an investigative journalist, spending 3 months, and fighting to have a FOIA request honoured.
It's an unfortunate naming collision.
My meaning: http://dnscookie.com/ RFC 7873 meaning: https://tools.ietf.org/html/rfc7873
The replacement battery was ~$7 USD including shipping, while the replacement screen (all-in-one digitizer/glass/screen assembly) was ~$15.50 USD including shipping.
The special screwdrivers/suction cups/spudgers/etc required to perform the procedure were included with the parts.
The swap process was relatively straightforward & lots of high quality photos/videos detail the entire procedure. Numerous guides are freely posted all over the internet.
Getting parts for a cheap Android device, however, proved more expensive than the cost of replacing the device (ignoring labor costs). The market is so fragmented it seems harder for an efficient parts supply chain to develop organically, let alone the knowledge/repair guides to effectively use those parts.
It has been in service since it was built for the 1986 World Expo.
Autonomous trains are not nearly as widespread as they could be, but this is not for technical reasons - it is for political reasons.
In comparison to the prior relatively unspecified approach to verification, it's still an improvement.
"The last person who touched needs to take ownership over anything anyone can blame on the change" is the management style which leads to enterprise IT being unable to get anything done. Because at that point, the safest thing is to never change anything - regardless of how bad things currently are.
Sometimes the world changes, and other parts of the technology ecosystem need to adapt.
[Editing to add since I can't reply to you]: The fundamental "flaw" here is that it's possible for people to get self-signed certificates served for domains where they haven't validated ownership of the domain.
Hosting companies can't be simply adjusting their routing tables for anyone who asks. If you are pointing a domain name at an IP address which will accept routes from any untrusted party, that's simply not a secure situation.
A signed certificate might be good evidence of some authority for a domain, but a self-signed certificate used in a challenge process most assuredly is not.
Even today, there are many hosting companies where you can go ahead and setup an account for "gmail.com" - and they will happily direct messages from their customers intended for "gmail.com". And there are hosting control panels where their "solution" to this problem is to have a hardcoded list of high value targets for which end customers cannot create accounts.
But the general issue is that providers need to be mindful of what changes they make to their routing tables. Not all inputs to the system are trustworthy.
Is not the real solution to have the confused deputies stop acting in a confused manner?
If this issue were confined to a handful of small hosting companies almost no one uses, then I don't think this would be described as a problem with Let's Encrypt - it would be described as a problem with those hosting companies.
The only party that can truly fix the issue of the incorrect user being granted access (directly or indirectly) to a domain pointed at shared infrastructure is the operator of that infrastructure.
A police department with frequent liability payouts can expect their premiums to be priced according to the risk they represent (assuming they are even able to find an insurer still willing to underwrite them).
These allow larger trades to be done without affecting the market price.
I agree with all your points about OAuth2 clients. But I would also add:
All clients (Amazon official or not) will ultimately need to have API keys compiled into them, and/or use a (less secure for the user) remote service to do the OAuth flow.
And for all of these clients, it will be possible for users to obtain the keys with some very simple reverse engineering and/or protocol analysis.
Which makes this entire thing seem like a real waste of everyone's time. Provide an API/service available on the internet, or don't.
Trying to tell people exactly which configuration of which software they should use to access your service is both disrespectful of your user's freedom as well as a fool's errand.
And now, without any warning, it is not. For many use cases, rclone is the only practical way of getting data in and out of Amazon Cloud Drive.
Amazon still hasn't bothered contacting me to let me know. Despite the fact that rclone was used with my Amazon Cloud Drive account daily.
"Oh hey FYI, we've disabled the app you use to access your data, good luck getting your data, have a nice day" would have actually been better than they approach they chose instead (disable my access + radio silence).
Fortunately I planned for this eventuality.
But this is yet another striking reminder of how foolish it would be to doing anything important while depending on just one cloud company.
After the thunderstorm, when the sun shines, often the clouds are no longer there.
On the router, without sending data to someone else's computer, it will give breakdowns based on Protocol & Destination (e.g. SIP, IMAP, Amazon, Facebook).
As I understand the definitions as downloaded periodically/automatically from Ubiquity.
So yes, this is not just theoretically possible, this capability exists in the marketplace, and it's demonstrably inexpensive to do.
Even protocol state (equivalents of TCP FIN/SYN/etc) is encrypted, to ensure that middleboxes don't get ideas about what the protocol is 'supposed' to do - ideas which make it hard to change the protocol in the future.
Some possible queries: "CF-Int-Brand-ID", nginx-cache "Certisign Certificadora Digital",
Once you find one, you can look through the results for unusual strings/headers which you can use to find more results.
Many results have clearly been removed from Google's cache, but.. many also have not.
It's mostly worked reliably in my experience (it's only failed to import one project across the various times I've used it, and I didn't bother debugging because for that import we really only needed the git data).