sp1rit

> your package manager that uses TLS would be vulnerable most distro package managers (dpkg, rpm, etc.) tend to use gpg which shouldn't suffer from those issues (but they could obviously still have some sort of other backdoor for gpg).

Still, I feel like distro packages are really secured compared to stuff you install via pip/npm/... as I don't believe they do anything beyond protecting downloads with TLS.

This might be the case, but how could Mazda even prove this? Unless they communicate in some weird proprietary binary protocol I could imagine that the API (especially if it's just some JSON/XML REST stuff) can be reverse engineered by MitM traffic analysis.

The takedown request is based on

> MNAO analyzed some of the code and determined that the code provides functionality same as what is currently in Apple App Store and Google Play App Store.

Is this really legal? Because in my mind, providing the same functionality does not violate copyright, since the actual intellectual material is new. And I don't think Mazda has a patent on the ability to control your vehicle over an API.

> 16k lines of obscure C, riddled with pointer magic and arcane memory manipulations? No thanks

Given the popularity of the library I'd imagine it's quite well tested. I also fail to understand why he attempts to port libshine from C to Go when he could just port the header files from LAME as FFI bindings instead. That should also ensure comparability with windows, as I'm sure such a library us also buildable on windows, given that ffmpeg uses it and ffmpeg works on windows.

I don't think this has anything to do with "attack surface". This is simply to avoid google collecting ip addresses.

Running nginx might be marginally faster than PHP, but I believe the latency to your server will be far greater than the time it takes the server "to spin up the php interpreter" (doesn't even happen anymore when using FastCGI).

Yes, this is certainly more "far-reaching" than other env vars. But If you have the ability to wreak havoc even if ld-linux wouldn't check for this (obv. PATH being the prime example, but unsetting HOME will almost certainly break some software written by novices (not falling back to the home specified in /etc/passwd)).

And I also could imagine that tools that allow setting arbitrary env vars might filter common troublemakers like PATH, but almost certainly not niche env vars that change the bahviour of ld-linux.

Not really. Realistically you can set PATH to an empty string, and block execution everything that isn't invoked using a hardcoded path.

There is also gobject-introspection[0], which is also capable to generate bindings for quite a lot of higher level languages from (gobject based) c-code.

I'm always impressed on how simple it is to use an object I defined in c within python.

[0]:https://gitlab.gnome.org/GNOME/gobject-introspection

I remember my old Nokia brick having the ability to send files and apps through an infrared thingy on its side. You could simply hold two phones side by side from each other and transfer data, but I remember handly anyone using it (I guess it was kind of akwad to use - but probably still simpler than getting the devices paird with bluethooth).

It wasn't nearly as fast the advertised speeds mentioned in the article.

Since there are absolutely no sources/further links in the article I could look at, is this based on David Chaums Ecash?

Because that actually looked like a decently private central-ish digital currency.

Surprisingly, the system of vendor provided ratings are now used by Freedesktop in their AppStream metadata[0] named OARS[1]. But it's a lot simpler that this custom DSL that IE used for content rating.

[0]: https://www.freedesktop.org/software/appstream/docs/chap-Met...

[1]: https://hughsie.github.io/oars/

Does this mean I can now finally generate object files from .rs sources and link them myself?

That is one of the things that rustc is severely lacking.

Keep in mind that Cannonical Ubuntu used to display ads/"recommendations " for Amazon products in their launch center thingy.

> "You see how there’s a space before the exclamation mark?" he said. "Yeah, that’s how 18-year-olds type."

I have never seen any 18-year-old type like this. Is this actually common in the US or just a thing of older folk imaging how an 18 -year-old might type?

> Is, according to their github page, a nary 18 years old.

a bit further down he actually proclaims being born 11/11/2004, making him just 17. No idea why he has 18 y/o in his user description, not that it'd make a difference tho.

Couldn't agree more. Using the webapp with a chromium-based browser is such a better experience (working screen-share, hw-accel, etc.) I couldn't imagine going back. And especially with chromiums --app flag (I just have a .desktop file that Execs `flatpak run com.github.Eloston.UngoogledChromium --app=https://discordapp.com/channels/@me --enable-features=UseOzonePlatform --ozone-platform=wayland`) it really feels like an "app" experience (exception being, that pressing on links in chat opens them in a new chromium window and not firefox).

There is a lot more discussion on the same email that was posted to the opensuse-project list: https://lists.opensuse.org/archives/list/project@lists.opens...

A cool thing rpm(build) does, is that is automatically detects shebangs of packaged files and makes the built package depend on whatever package provides the file the shebang points to. This obviously cannot work for env shebangs, so you always have to do that find -exec sed dance to replace them with proper ones for software that decides to have env shebangs.

But on Linux we also don't have to fight with a 15 year old bash or "compromising" a system when installing something into /bin. It feels lile OS X genuinely doesn't sound like a good UNIX to administer.

This is probably a common flaw in a lot of applications with a lot of complexity layered below the main product.

Electron applications are a prime example of this, since there is a whole webbrowser underneath and HTML doing HTML things is expected behavior for the browser, but not the application above. One can probably attribute the whole log4j debacle to the same fault, in that the "common" developer is unable to understand all complexity and quirks their software ships with (difference being, that a browser engine is far more complex than a logger)

I remember a time where "Scrach" wasn't a Electron application, but a native (I think?) Linux application. Obv. there can be bugs in dependencies too (rsvg, libpng, etc.) but they different and tend to not be as easily exploitable as these kind of Electron/HTML->V8 bugs are.

(2019)

What alternative to a users passwords do you have in mind?

The only other potential cryptographically secure alternative might be a TPM chip, if a machine has this. However since a TPM stores secrets system wide, keyrings for each user seam unfeasible and it's likely less secure since you could just boot into single user mode and get the TPM secrets.

Additionally I tend to not trust the TPM (esp. on Linux), because if one firmware update somehow fails to apply properly, I'll have a far more nastier time (since all secrets are gone) than GNOME Shell promoting me to insert my old password.

> let alone have bindings for languages like Ada.

Language bindings for any GObject powered are usually automatically generated from their introspection data (.gir) generated from g-ir-scanner.

So that wouldn't be the issue.

> For the purpose of the demonstration, we're going to use Gtk.Grid to create a grid container widget.

why exactly? a GtkBox is would do just fine, looks better and it's easier to handle programmatically than the grid.

For Android there is also the free alternative to Apples Android AirTag called "AirGuard"[0]. It was out way sooner than Apples application and seems to be far more advanced than it (i.e. has the features you claimed the apple android air tag application was lacking).

[0]: https://f-droid.org/packages/de.seemoo.at_tracking_detection

Yes, down in Europe too :/

https://downforeveryoneorjustme.com/github

line 559

> China has no freedom of speech

whoever wrote that into "illegalwords.zh-CN.en.txt" must have been aware of the irony...

> Some of the stuff you mentioned seems to cover computer to computer, but isn’t relevant to computer to mobile scenarios.

no, the things I listed are how I sync my linux machines with my mobile phone.

I wasn't talking about computer to computer sync, but the methods I listed (maybe except kdeconnect, which is built for computer to phone sync) apply to workstation to laptop sync aswell.

> You can't 'selfhost' this stuff.

you can,

- kdeconnect can do clipboard & messages sync

- nextcloud (or anything else that does webdav & webcard) does calendar & contact sync

- Firefox (and chrome probably too) can sync browser history and share webpages feom one device to another

i'm not aware of anything that can remotely unlock another device, but that seems like a security risk to me (also quite hard to implement as pam is synchronous :/).

but you certainly don't need a closed ecosystem, building your own out of free components is very much possible.

you can "opt out" using adb by revoking the gyro permission. some non-google androids also have the possibility of revoking it with the ui, or even going as far as to promt for it (graphene os)

It isn't a new currency in the sense that you can, as a central back, configure the server to use "your" currency, and begin converting cash into taler tokens.

For the demo it's unfeasible to use a preexisting currency, because they can't give out free money :-). So the obv. solution was taken to configure their server for a imaginary currency (KUDOS & TESTKUDOS) 100 if which are created out of thin air after you register.

To get started, I'd recommend downloading the wallet (extension or mobile[0]) and registering an account with their demo bank. With the creation of that account, you should receive 100KUDOS tokens of which you can withdraw to your mobile phone / extension. Do so and you'll get a QR code to scan with the amount of KUDOS selected on the web interface. With that "money" you can now go to their demo shop and "buy" excerpts from rms's Free Software, Free Society, or "donate" to a few projects (try donating 5 kudos to simulate a malicious merchant), by again, scanning a QR-Code.

If you want to know the details, I'd recommend the paper "How to issue a central bank digital currency[1]" which is very much like Taler.

    [0]: https://f-droid.org/packages/net.taler.wallet.fdroid

    [1]: https://www.snb.ch/en/mmr/papers/id/working_paper_2021_03