GCP patched a similar loophole [1] in 2023 presumably because some of their customers were abusing it. I'd expect AWS to do the same if this becomes widespread enough.
Unlikely. The "loophole" GCP patched was that you can use GCS to transfer data between regions on the same continent for free. This is already non-free on AWS. What OP mentioned is that transferring data between availability zones *in the same region* also costs $0.02 per GB and can be worked around.
This doesn't feel like a loophole though, it feels like they have optimized S3 and intend your EC2 instances to use S3 as storage. But maybe not as transfer window, that is, they expect you to put and leave your data on there.
macOS has native password autofill which opens the Keychain experience to 3rd party password managers. Unfortunately browser support is limited to Safari (even though the API itself is open), while Strongbox [1] seems to be the only option on password manager side.
Maybe this will improve with the adoption of passkeys, where browsers are actually trying to integrate with the system passkeys API (a neighbor to autofill).
Unfortunately, removal of PIIs also means less data/cues for hard-to-diagnose bugs (it can even range to CPU bugs like [1]). For Firefox, potentially PII-containing memory dumps are still sent to the server, but they're only viewable by authorized personnel [2].
There are also rule-based PII removal methods as used by Sentry minidump processing and described at [3].
IMHO, perf's decision to write whole stacks directly to the disk and unwinding them as a post-process is a really bad design. It wastes disk space, and as the author pointed out, it also has a lot of IO overhead.
As an alternative approach, https://github.com/mstange/samply processes data streamed from perf and unwinds it in realtime. The unwinding overhead is surprisingly low: it only takes around 1% of (single) CPU per CPU profiled. Solving the disk waste alone has been a tremendous improvement of profiling experience. As a bonus, the unwinding and symbolization works reliably while I frequently had postprocessing not terminating when using the perf CLI directly.
Are you saying that Dwarf information should be unwound in realtime or that it should use framepointers and debug information to trivially sample the stacks and record the symbols?
If you have framepointers and debug information, it is both high resolution and fast. DWARF is a fallback for not having framepointers.
If you are saying the DWARF information should be processed at the point of use and not copied and processed later, then I concur. But we should also encourage folks to compiled WITH `-fno-omit-frame-pointer` and `-g`
Rellic [1] implements an algorithm that generates goto-free control flows (citation in README), which would be a significant improvement against what Ghidra/IDA generates currently.
Unfortunately it looks like the maintenance state of the pieces around Rellic isn't very good, and it's quite rocket science to get it building. It doesn't have as much UI/GUI as Ghidra either so it's a bit far from accessible right now.
From reading the paper, it basically does jump unthreading. Basically, if you imagine code like this:
bool found = false;
for (...) {
if (...) {
found = true;
break;
}
}
if (found) {
// A
} else {
// B
}
Jump threading is an optimization pass that replace the break statement with a goto A. After that replacement, found is always false, so the boolean variable and the if statement is deleted. The resulting code would look something like this [1]:
for (...) {
if (...) {
// A
goto end;
}
}
// B
end:;
What the lifting is doing here is essentially running this pass in reverse. If you find a branch pattern that doesn't meet any preordained schema (such as a loop with multiple exits), just synthesize a variable that tells you which target you're going to jump to. Were the compiler to optimize the resulting code, jump threading would convert it back into the gotos present in the compiled binary.
[1] This kind of optimization pass runs at a stage when the code is basically treated entirely as a CFG and there's no such thing as if statements or jumps or gotos, just conditional and unconditional branches terminating basic blocks. Any reflection of the code outside of this form is therefore somewhat imprecise.
[EDITED to say explicitly:] You can translate any goto-laden code into "conventionally structured" code mechanically, if you don't care about having the structure of the resulting code actually indicate what it does. Here's an example of the sort of code for which that might be the best you can do.
Suppose you implement a state machine with gotos. So, for a simple (and contrived) example, suppose you have something that absorbs the decimal digits of a number and keeps track of the value of the number modulo 3 by having three states. Something like this (pseudocode):
def mod3():
state0:
d = getdigit()
if d == FINISHED: return 0
if d is 0, 3, 6, 9: goto state0
if d is 1, 4, 7: goto state1
if d is 2, 5, 8: goto state2
return ERROR
state1:
d = getdigit()
if d == FINISHED: return 0
if d is 0, 3, 6, 9: goto state1
(etc.) You've got three stateN labels each of which can jump to any of the stateN labels (as well as being able to return from the function).
If you have tail-call optimization you can turn this into conventionally structured code, more or less:
def state0():
d = getdigit()
if d == FINISHED: return 0
if d is 0, 3, 6, 9: return state0()
if d is 1, 4, 7: return state1()
if d is 2, 5, 8: return state2()
return ERROR
with similar definitions for state1() and state2(), and then the top-level function just calls state0. But this depends on knowing that all those tail calls will get optimized, or else on never having enough digits to overflow your stack.
Or else you can have an explicit state variable:
def mod3():
state = 0
loop:
if state == 0:
d = getdigit()
if d == FINISHED: return 0
if d is 0, 3, 6, 9: state = 0
else if d is 1, 4, 7: state = 1
else if d is 2, 5, 8: state = 2
else: return ERROR
else if state == 1:
...
else:
...
which works pretty well for the special case of state machines but badly for most other things a goto might be used for. (Though obviously you can translate literally any goto-using code into this sort of thing. You might want to call the analogue of the "state" variable here "program_counter" in that case.)
The translation can always be done, but for dense spaghetti control structures duplication of code may be required. One can construct artificial cases where the size increase is exponential, but that's unlikely to be an issue in even the worst real code.
This is actually why we chose _not_ to implement no-more-gotos for Binary Ninja's HLIL! Code is actually more readable with gotos in some situations and trying to force their elimination hurts readability.
Can't relate. Tailwind works fine with anything that supports PostCSS. I run it with Vite and there's zero issues.
> the state management ecosystem is fractured between vuex and pinia
This is also just not true. Pinia is officially replacing Vuex as the recommended store library for Vue [1]. They're also vastly similar in how they do things, so the knowledge transfer over from Vuex to Pinia. And Pinia just address most of the design goals mentioned in the article in the most simple way.
As for Vue 2 -> 3 transition, lots of the larger UI frameworks in the ecosystem is struggling to migrate, despite lots of efforts on the compat layer to smooth the transition, which is a bummer. But as long as you're not doing those sophisticated things, Vue 2 examples should work out-of-box on Vue 3 as well. There are surely less resources for the composition API, but the official introduction guide has been good enough in my experience.
> As for Vue 2 -> 3 transition, lots of the larger UI frameworks in the ecosystem is struggling to migrate, despite lots of efforts on the compat layer to smooth the transition, which is a bummer.
I actually recently looked into most of the frameworks out there and their migration efforts.
So far, I only found three viable options for Vue 3:
- PrimeVue https://www.primefaces.org/primevue/
- Quasar https://quasar.dev/
- Element Plus https://element-plus.org/en-US/
We went with PrimeVue and while using PrimeFaces was an incredible pain with Java, the Vue version seems a bit better. Then again, it's kind of odd that libraries as popular as Bootstrap don't have complete bindings in the form of Vue 3 components.
Carbon is absolutely amazing. They are using a very flat style in pursuit of a modern corporate brand, just like a lot of other tech companies today, but the design also incorporates a lot of traditional and familiar elements. It’s a rare instance of flat UI that does not feel mobile oriented and half assed on desktop.
Carbon components are also the most accessible component set I have seen, and they go through great lengths doing automated and manual accessibility testing.
The library though, is a bit lackluster. It’s tailored for IBM’s internal need, and is still a bit far from a complete framework. So you need to be prepared to write some CSS as well as designing your own components when you need one.
[1]: https://cloud.google.com/storage/pricing-announce#network