Couldn't the correct function signatures be generated from the COM type library? Using an LLM for this is clearly not a good fit, as the article demonstrates.
LibreOffice is derived from OpenOffice.org which is derived from StarOffice which predates Java. When it was acquired by Sun and open-sourced, they added some optional components implemented in Java, but the core application is not a Java application. The GUI is not Swing but their own custom GUI framework (not based on Java).
Never mind the December security patches, Samsung haven't even released the November patches yet, the ones for the critical severity RCE. Unless you have a "major flagship model" [1], because apparently only the richest users deserve to be secure.
Why would you want security, if you get 'play integrity' for phones that received no updates since 2 years. Google's current security practices are more than dubious IMHO. Now they are not releasing any source for security patches for 3 month, to 'protect' vendors that are too slow updating. As if there is no chance for bad actors to reverse engineer those patch sets.
I have the strongest level of "Play Integrity" on a Xiaomi phone that hasn't received any updates since the beginning of 2020. Google Pay and co work fine. It makes sense when you remember that PI is not about security at all, that's just an excuse.
Elaborate please. PI on its own is just an insurance API for banking and similar apps to ensure that they can do secure compute on the device. It can also be used to check if the device that the app is running on is a genuine Android device, since no VMs or custom ROMs can pass hardware integrity.
Very old, unpatched and rooted devices can fairly easily pass device integrity check.
It primarily assures the software vendor that the phone is running Google buttplug in the privileged mode.
Remember, handsets running on ANCIENT versions of Android with no patches for years. Whilst seems to be important to raise under the Forbes article (rightly) fussing about a couple of zero-days.
"Custom roms" (whatever that means) can easily spoof the checks in the specific situation (mainly hardware that allows for several things).
What sense is does it make to certify an insecure device that may be subject to all kinds of remote exploits and elevated code execution as 'unmodified'. The argument of the banks is: the device is insecure (even with the latest patches). We all know the whole compliance is a bit more complex, so it might make sense on that level...
Pixel 6a used to show a September patch as the latest, but tapping "check for updates" found a new one. As mentioned in other comments here, apparently tapping those buttons twice may help.
Says September is the latest system update. Click check updates, says it's up to date, click check updates again, says it's preparing system update and hangs out for a while - then says it's downloading and installing a 781M update.
WTF?
Update: OK finally the update completes an hour later, even the reboot took longer than usual - says it's "updated to December 5, 2025"
This phone running Android 16 for a bit over a month now.
The December updates for Pixel 7 and Pixel 7 Pro are available to manually download on Google's website [0], so the updates do exist, although Google might not be rolling them out to the general public quite yet. But the December update for Pixel 7a are completely missing from that website, and trying to update from the Settings app also shows no updates available.
There are instructions at the top of the link. You need to use "adb" from the command-line on a computer, but it won't wipe any of your data, so it shouldn't cause any data loss. If you don't want to use "adb", you might be able to use [0], but I haven't tested it myself.
I thought Google was moving stuff out of the open source stock android branch and into their proprietary pixel development branch, such that the functionality of stock android has been diminishing to the point that a phone running stock android would be barely usable as the device we'd expect. Maybe I've read wrong and misunderstood though.
The funny thing about the last one is that those actions ultimately boil down to invoking their CLI tool (which is pre-installed on the runners) with "gh release create ...", so you can just do that yourself and ignore the third-party actions and the issues that come with them. Invoking an action isn't really any easier than invoking the CLI tool.
Yeah, what really needs to happen with that repo is to put that in the README to use the gh CLI instead of pointing to the third-party action with questionable security policies. If they were accepting PRs for that repo, it would be an easy PR to make.
> post your applet on a web page, and anyone on the planet could run it instantly
"Instant" is a strange choice of words to describe JVM startup performance. I recall the UX of encountering an applet involving watching a Java splash screen while the browser is frozen.
The alternatives to Java were just as bad. Flash and friends were fast but couldn't do anything more complicated than animation for most of its life. In the Java heydays, you were doing either Java or custom ActiveX plugins, and both led to security popups galore and random browser freezes.
However, ActiveX usually required you to install components, while Java could just run first time.
What I would really like is a Git equivalent to Mercurial's "fold" operation. I usually make a bunch of commits as I work, just as checkpoints, which I then want to turn into a single final commit when it's done, which could be quite some time later, e.g. "started on thing", "broke it", "broke it more", "Add thing to improve foo of bar".
Mercurial's "histedit" command offers two operations to combine the commits: "fold" and "roll", where "fold" brings the earlier commit into the later commit and "roll" does the reverse. The "fold" operation does exactly what I want in this case: It brings all the changes into the final commit from when I actually finished it, using the commit date of that commit.
Git's "rebase -i" command offers "squash" and "fixup" and "fixup -c" and "fixup -C", but they all do the same thing as "roll", i.e. they keep the earliest commit's date, the date when I started working on the thing and not the date when I finished working on it. (So I then cut and paste the correct date and update the commit afterwards. This may not be the best way to do it.)
That is an interesting desire to use a later commit date rather than an earlier one. So many prefer that commit date of when an effort started.
One way to accomplish that is to reorder the commmits in `rebase -i`: "pick" the last commit first and squash/fixup the rest after. That can produce some very weird merge conflicts, but it works well more often than you might think, too.
At the very least, you can do your hand editing of the commits during the rebase instead of after by switching the earliest commit from "pick" to "edit" to have the full power to amend the commit before it moves on (with `git rebase --continue` when you are satisfied). (Versus "reword" if you just want to change the commit message only.)
Also, instead of naming commits things like "broke it" and "broke it more" an option is to use `git commit --fixup={previous commit hash}`. That auto-generates a "fixup!" name based on the previous commit and auto-marks it as a fixup if you use the `--autosquash` flag to rebase.
I do use fixup commits as well, for fixing small issues discovered after I make the proper commit, and in that case it makes sense to use the date and message of the earlier commit.
But in the case I'm describing, the earlier commits are essentially just temporary snapshots on the way to making a proper commit. Just a more explicit undo history, basically. I usually don't even bother naming them anything as meaningful as "broke it", actually. Maybe most people wouldn't even bother making these commits – or maybe they would if Git supported "fold".
My pattern in a case like that is often to start a commit named "WIP thing I'm doing" and `commit --amend` each snapshot, updating the commit message as it starts to come together. `commit --amend` is nicer/gentler than `rebase`, most of the time.
Though there are also times I don't mind working in a very dirty worktree and `git add -p` (interactive add that also makes it easy to stage only parts of files) pieces only once they feel complete and start to tell a story. (And in those cases I may use a lot of `git stash -u` and `git stash pop` snapshots, too, especially if I need to switch branches in that worktree.)
Hmm, I may have actually solved my problem. I think what I mostly want to do is this, if I'm working on the "feature-1" branch based on "main":
$ git checkout feature-1
$ git reset main
$ git commit -a -C feature-1@{1}
This squashes all the changes and keeps the date and and message of the final commit on the branch.
Weirdly, although the "-c" and "-C" flags for the fixup operations sound like they should correspond to the same flags for "git commit", which grabs the date along with the message from the specified commit, the fixup flags only affect the message and not the date.
It would be nice if it worked the same for rebase as for commit. Then "fixup -C" would essentially correspond to Mercurial's "fold".
Ah, yeah, that use of `git reset --soft` is how many places do squash merging, so that makes sense. You may want to make sure to include the `--soft` flag explicitly just as a precaution.
Also yeah, I would expect the fixup -c and -C flags to be more aligned with commit in a rebase.
git fixup doesn't take the old commit message either, so I would be not so surprised that it doesn't take the commit message. It is really for preparing to do rebase fixup to the older commit.
How? I tried recreating the scenario from the article (the section "First rebase –onto") and ran the first rebase with "--update-refs":
$ git checkout feature-1
$ git rebase --update-refs main
Successfully rebased and updated refs/heads/feature-1.
Updated the following refs with --update-refs:
refs/heads/feature-2-base
But all it did was update feature-2-base. It still left feature-2 pointing to the old commits. So I guess it automates "git branch -f feature-2-base feature-1" (step 3), but it doesn't seem to automate "git rebase --onto feature-1 feature-2-base feature-2" (step 2).
Yeah, you need to rebase the tip of the feature branch stack. git will then update all the refs that point to ancestor commits that are moved. So in this case
The lithium-ion battery analogy seems fitting: When we're not careful about sourcing those modern batteries from a trustworthy supply-chain, they tend to explode and injure the user.
But is it a good idea to make it seamless when every crossing of the boundary has significant implications for security and performance? Maybe the seam should be made as simple and clear as possible instead.
It sounds related to me. The react.dev blog post [1] says that the vulnerability is
> a flaw in how React decodes payloads sent to React Server Function endpoints
and the react.dev docs for React Server Functions [2] say that
> Server Components can define Server Functions with the "use server" directive [...] Client Components can import Server Functions from files that use the "use server" directive
So it certainly sounds like the vulnerability is related to React Server Functions which are related to "use server".
I think the top-level comment was criticizing the entire feature (server functions) enabled by "use server". The vulnerability is in this feature, so (as I understand it) you're correct that grepping for "use server" won't find the vulnerable code, but if there was no such thing as "use server" the vulnerability wouldn't exist.
Oops, yeah. My bad, you're right. It makes sense that any flight server that is capable of interpreting server functions would be vulnerable whether the codebase used them or not. It's an issue in the transport mechanism and not the actual RPC implementation.
reply