Out of curiosity, could this have been a vector for a supply chain attack?
I am currently running an fairly outdated version of datatables on a personal project, v1.11.3 from 2021. I'm not too worried about running this older version, because according to dependency scanning software there's no CVEs for it [1]. Also, upgrading this package is too tricky as there's been some pretty huge breaking changes, so I'm stuck at this older version.
I am _not_ using the datatables CDN but instead self-hosting the static files. However, I did not notice until recently that in v1.11.3 it comes with a CSS stylesheet [2] that loads a static resource from that CDN: `url("https://www.datatables.net/examples/resources/details_open.p...")`
It looks like newer versions of datatables don't import static files from the datatables CDN like this.
Presumably if this domain was hijacked as stated in this incident review, users on affect datatables version could have had their site compromised?
Would it make sense to issue a CVE for older datatables library versions that could be susceptible to this attack?
> Out of curiosity, could this have been a vector for a supply chain attack?
If you were using the CDN without SRIs, then yes, that would have been the most obvious channel. However, I don't believe the attacker ever set up for that and the URLs never resolved due to CloudFlare blocking it.
> there's been some pretty huge breaking changes
Unless you were using the legacy API, there shouldn't be any major impediment [1]. I intentionally tried to keep backwards compatibility as I hate doing library upgrades myself! Drop me an email - allan at the domain in question if you have any questions about doing an upgrade.
> It looks like newer versions of datatables don't import static files from the datatables CDN like this.
I rewrote aspects to use CSS styled elements in place of images, so there were less resources to load.
> Would it make sense to issue a CVE for older datatables library versions that could be susceptible to this attack?
Per the above, if you were using the CDN without SRI for the resources, then any version could have been susceptible. However, I've seen no evidence that the attack took that vector.
I thought I was not using the CDN as I had self-hosted the static sources, but some image sources seemed to be imported from the CDN in stylesheets in the version of data tables I linked.
I just updated my application from v1.11 to v1.13 without any trouble (aside from some minor aesthetic changes to padding), so at the very least I now benefit from your styled elements.
Thanks for your dedication on this package, I’ve used it for years and it works very well.
I seem to recall enjoying using datatables. You, or somebody else associated helped me on the forums. Not sure what I asked but I remember two things: positive dev interaction, and the pain of figuring out how to make the OOX/Excel export not lose proceeding zeros. (Had to write my own handler to change the xml)
Offsite replica is only applicable if the cause is a failure of the primary. What if I’m restoring a backup because someone accidentally dropped the wrong table?
nah, on a long enough timeline everything will go wrong. blaming the person who managed to drop the table finally is dumb: if you can't fix literally everything that could happen to it, it's not done.
I’ve used this app for a while, it’s really good and I’d highly recommend it if you want to learn more about the birds where you live in an accessible way.
I recently upgraded two ~10 year old aging legacy applications at work. One was in Flask, and one in Django. This made me appreciate the "batteries included" philosophy of Django a lot more.
Even though the django legacy application was much larger, it had barely any extensions to "vanilla django". Comparably, the flask application had a dozen third-party flask-* dependencies that provided functionality like auth, permissions, and other features that Django has built-in. Many of these dependencies were archived/abandonware and hadn't been maintained in a decade.
When it came to upgrading the Django app, I had one giant release notes page to read. I didn't need to switch any packages, just make some pretty simple code changes for clearly documented deprecations. For the Flask app I had to read dozens of release notes pages, migrate to new maintained packages, and rework several untested features (see: legacy application).
In my mind, "batteries included" is an underrated philosophy of Djangoo. Also, it is now such a mature ecosystem it is unlikely there will be any radical breaking changes.
Perhaps there are some parallels to draw with newer trendy (but minimalistic) python frameworks like FastAPI.
If I were building a web application I wanted to last a decade or more, Django would be up there in tech choices - boring and sensible, but effective.
In Bing Maps, I expect them change country borders based on localization settings, but that was probably too onerous to implement and test in the Windows 95 days.
I remember when this happened, which I guess makes me very old.
They didn't actually remove the map - they just removed any functionality it had. So the time set window is massive for no reason, it contains this huge world map bitmap that no longer does anything.
They eventually did remove part of the map: because of politics and timing, Poland was accidentally removed despite the map time zone picker no longer working, because the dedicated Polish timezone the green pixels were attached to were removed.
Think of the dev/test/PM people who worked on this feature.
It's not a standard Windows control, so there had to be lots of work to get the timezone boundaries, map to values usable for their world map bitmap, iterate a bit on the behaviour for when the user clicks at x,y on the map, et. al.
The elation of shipping the minor feature, followed a few months later, with the realization that most of that work is going to be neutered.
Or just refuse to commit. E.g. Google Maps, to this day, will not show the country for any Crimean city when you click on it to bring up its info panel. If you do this with e.g. Kherson, you get "Kherson, Kherson Oblast, Ukraine". But if you do it with Sevastopol, you only get the city name, not the region & country. It also shows dotted borders between Crimea and both Russia and Ukraine.
Isn’t Google Maps blocked in Russia anyway? Crimea is a different story, as many countries recognize it to be in some kind of limbo and treat it as neither Russian nor Ukrainian.
I think Yandex (Russian Google) removed borders completely from their maps. Also because it’s impossible to figure out where the Russian government would like them to be. Might change on a daily basis.
Google maps added the „gulf of America“ to their US version, because anywhere else it’s still the Gulf of Mexico (even in iOS autocorrect, it changed it correctly to uppercase).
Google did this way back, sometime in 2016 IIRC, before they were blocked in Russia. I'm not really sure why they still keep going with this esp. since they still show the entirety of Donbas as Ukrainian, and it has been occupied for just as long as Crimea has been.
Yandex censorship around this is really amusing. They did indeed drop all mentions of countries and borders everywhere, for one thing. But also in Alice (their LLM chatbot), it's to the point where if you ask it to prepare a road trip from Sochi to Bucharest and describe the route in detail including which countries it passes through, it refuses to answer.
the "gulf of america" thing is Google pandering to Trump, they originally had a policy of only using the popular name in a given locale.
> if a ruler announced that henceforth the Pacific Ocean would be named after her mother, we would not add that placemark unless and until the name came into common usage.
that's different, they had location-dependent names at the time of this article too, the issue is specifically about the fact that even if you have location-dependent names you'd use the name that is commonly used in that location, not an arbitrary regulation name.
I thought they used the Geographic Names Information System (GNIS) from the USGS. If this buffoonery does pass, it will reflect in the government official data source - and thus on Google maps?
And nobody outside of the US cares about what's inside those official databases. If Trump changes the name of China to "Smelly Food Country" it might be required to change this in US Google Maps But if this propagates to Google Maps in other countries people will just laugh at them and might stop using it.
But they should see what their home country calls it? I am totally against this, but don't really think Google is bending the knee or hard-coding a name here.
What does "actually in control" mean? When the IRA set up a checkpoint in Rosslea, should that have moved the border on the map? When there are disputes over uninhabited islands, do you want it to show whoever visited first? Obviously these are small examples, but the same issues apply to full-scale civil wars.
You'd also be essentially legitimising the right of conquest if as soon as country A invades country B you move the border on the map. That would be pretty counterproductive.
> You'd also be essentially legitimising the right of conquest
Documenting reality doesn't endorse what happened. Istanbul was Constantinople. Shit happens. If I'm travelling, I'd much rather the flags and borders reflect the situation on the ground instead of making meaningless humanitarian gestures.
The issue is reality not being settled or agreed upon. For disputed territories there is effectively two realities both officially backed by sovereign countries.
You can come up with some arbitrary criteria to split the difference, but your reality would break when you effectively set foot in a spot that works under the competing assumption.
The issue is reality not being settled or agreed upon. For disputed territories there is effectively two realities both officially backed by sovereign countries.
No, in a disputed territory there's one reality, and 1..n delusions.
Well, maybe that's what the victor will write in the future history books, but since today's mapmakers don't know who's going to win that's not really a helpful perspective.
For each "disputed" territory there is only one party actually in control right now. If you bothered to actually travel to e.g. Taiwan you'd quickly find out that the PRC's opinions are irrelevant.
> For each "disputed" territory there is only one party actually in control right now. If you bothered to actually travel to e.g. Taiwan you'd quickly find out that the PRC's opinions are irrelevant.
If you bothered to actually travel to Ukraine you'd find there are plenty of places where you can get dronestruck by either side. If you bothered to actually travel to the disputed India/China/Pakistan border area you'll find either side might hit you with a stick and take you into custody. If you'd lived in Northern Ireland 40 years ago, or even South Italy today, you'd find that the group that enforces its laws with force in your street might be quite different from the group that is internationally thought to be "in control" of the country you're supposedly part of.
Control is not a binary. There's no country in the world that doesn't have murders, kidnappings, and takeovers. When (as in South Korea recently) there's a group of people outside a guy's house who say they're coming to arrest him under a warrant from the Supreme Court, and he says he's the President and the warrant is illegitimate and they're just a gang of thugs trying to kidnap him, who is in control? There's no way to answer that except retrospectively. When armed men declare independence or a revolution, are they "in control" of an area in a sense that should be shown on a map, or just regular criminals? Again, no way to tell.
I'm quite familiar with Taiwan thank you very much, and yes it's one of the more stable situations (although these things have a way of seeming stable until they suddenly aren't) where one of the claims is rather attenuated and silly. That doesn't mean there's a simple, easy solution to territory disputes in general.
The situation on the ground is that if you, say, visit Crimea by obtaining a Russian visa, you might not even be able to enter Ukraine afterwards. This feels like something that also needs to be reflected.
It's the opposite of meaningless. Delegitimising wars of conquest massively reduced them and was a big part of why the 20th century was so much more peaceful on the whole (yes, even with the giant wars that did take place) than those before it.
The Kashmir region north of New Delhi is an interesting example. Even in the US, Google basically says you're on your own, but here's a collection of dotted lines that may or may not be the actual borders.
Basically any large platform that renders map data realizes pretty quickly that you have to adjust it country by country to accommodate everyone’s irredentist claims and naming disputes. I suppose there’s no reason they couldn’t ship different system fonts to different countries, but that introduces a lot of annoyance and room for error for a somewhat marginal use case.
BTW the USA is now one of these "sensitive countries" where apps have to lie to legally do business. Just like Chinese users see Taiwan labeled as China, American users see (or will soon see) the Gulf of Mexico labeled as the Gulf of America.
1) Don’t lie. Apps don’t have to “lie” to do business in America. If someone labels the Gulf as the “Gulf of Mexico”, there’s not really a goddamn thing the Federal Government can do about it except throw a shit fit. The fullest extent that they can enforce this is on contractors making products and services specifically for the Federal Government’s and Military’s own use.
2) Maps apps are probably going to relabel it as the Gulf of America anyway within America, and it’s not exactly a lie. Barring any issue with Congress, if there’s some statute buried somewhere that legally enforces the name of the Gulf to be the Gulf of Mexico, it isn’t exactly a lie if the President exercising the authority of the Office of the President renames a geographical feature that’s at least partly touched by the US. There’s a lot of geographical features that have different names either in different languages, different locales or both, and it’s fully within the Executive branch’s purview to name them. They do so all the time, although typically for the more obscure things nowadays since for anything too prominent, the name was decided long ago.
Maps apps can set their own policy on this, but generally the easiest course of action is to defer to governing authorities.
I mean if you’re conflating invading and annexing parts of or whole independent nations with the naming of bodies of water and other geographic features, I can’t help you with that one. You’ll need a professional. That’s not even half the gotcha you think it is.
I’m not even one to defend the PRC, but between the PRC, the Republic of China, Korea, Japan, and Russia there’s a lot of land and naming disputes between them.
I have some first-impressions feedback after playing with it for ~15 mins:
1. Setup was super easy. Aside from Goland/Pycharm marketplace search weirdness, I was up and running in ~30 seconds.
2. The branch dropdown is a little crazy in some of our repos. We don't have very good branch hygiene, so have hundreds/thousands of branches in the dropdown. I'm unsure how easy of a feature request this is, but it would be nice to order the repos by activity (e.g. most recently committed branch first).
For now, filtering them by my own GitHub user was a fine workaround, as it's then easy to find the workflow run as those /are/ ordered by most recent first.
3. I found a potential bug in the grouping of pipeline step logs. For context, I have a multi-step pipeline. For the first few steps the logs appear on the correct step, but after a specific step the logs appear in the n+1 step's place.
The incorrect indexing seems to be caused by a step that invokes another action via the `uses` block. It looks like this:
- name: Setup foo
uses: ./.github/actions/foo
with:
api_key: <REDACTED>
- name: Build bar
run: make bar
- name: Run baz
run: ./baz
The first part of the logs stating "Run Setup foo" appear in the correct step, but the logs from the "./.github/actions/foo" action appear in the logs for the "Build bar" step incorrectly, and the /actual/ logs from "Build bar" appear in the logs for "Run baz" (so all the logs appear in place of the next step's logs, I guess because the indexes are messed up).
4. If I expand a pipeline's logs with a lot of lines (~67,000 lines) it crashes the extension. (In fairness, in the GitHub actions web UI it says "This step has been truncated due to its large size. Download the full logs from the menu once the workflow run has completed." - so it is a bit excessive.)
Specifically, when I expanded a pipeline step's logs and got "Oops! Something went wrong. We encountered an unexpected error. Try reloading to reset and continue." - when I hit reload it did fix the application, but it loaded the "home" page rather than the pipeline page I was on, and removed all the branch/user filters I had previously entered - it would be nice if these got preserved even if the extension crashes.
If I reopen that same pipeline step's logs I can reliably reproduce this breaking the application every time (tried 3 times).
5. The pipeline logs don't correctly handle symbols and color codes. For example, I have a log that says " YN0000: Successfully set npmRegistries["<REDACTED>"] to undefined", and the "undefined" text appears in grey on the web UI. (I believe the "undefined" comes from GitHub Actions' automatic scrubbing of secrets from the logs.)
In the plugin this log appears as: `[39m YN0000: Successfully set npmRegistries["<REDACTED>"] to [90mundefined`
6. No search functionality or scroll bar on step logs. Suppose my test fails in CI and the result is right at the bottom of 70,000 lines of test logs, I need to be able to easily find that for this plugin to be helpful.
7. After installing the plugin and connecting my GitHub account, I got an error:
"The plugin io.revenate.actionate failed to save settings. Please restart GoLand". However, I think it was a false-positive, because the extension is working just fine without a restart!
Thank you so much for your feedback—it’s truly valuable to us. We do our best to test thoroughly before releasing, but we know we can’t anticipate every scenario. The issues you’ve highlighted are extremely helpful, and we’ll be prioritizing them in our next release.
Regarding the error you encountered after installing the plugin and connecting your GitHub account—"The plugin io.revenate.actionate failed to save settings. Please restart GoLand"—this does appear to be a false positive. Behind the scenes, we use the built-in IDE mechanisms to persist the selected GitHub account, and sometimes the IDE throws this error when attempting to save the settings file for the first time. This happens because the IDE tries to back up the settings file before persisting changes, and intermittently fails to detect that the file doesn’t exist yet. We’ve already reported this issue to JetBrains.
As for your feedback about the lack of search functionality and scrollbar behavior in step logs, you're absolutely right—log search is a critical feature, and it's planned for the very next release. Regarding the scrollbar, our UI leverages the JetBrains embedded JCEF (Chromium-based) browser, and its behavior can vary depending on the IDE version. In some versions, the scrollbar is always present, while in others it only appears when scrolling. This behavior is controlled by the underlying JCEF implementation, and we’ve also raised this issue with JetBrains.
We sincerely appreciate you taking the time to share your thoughts, and your feedback helps us improve Actionate to better serve our users. Please keep the suggestions coming—we love hearing from you!
Even with YouTube Premium you don’t get the feature set you get with SmartTube. The sponsor block integration on my TV is brilliant.
reply