dbrgn

Instead of attacking the person (ad-hominem), how about discussing the technical merits and deficiencies of the proposed solution to a real problem that no Linux distro has tackled so far?

I'm sure the NSA is happy about unauthenticated initrds. I'd be very surprised if such manipulation was never used in practice.

Yeah, I have good experiences with Mattermost (bundled with GitLab) as chat for a hackerspace/makerspace. As long as you're OK with unencrypted push messages, building your own version of the app and keeping it up to date is horrible. (React native levels of horrible.)

Rocket can be used with sync handlers.

I've memorized my last 2 credit card numbers. Takes about 5-10 minutes and is absolutely worth it!

Different organizations have different requirements, so they choose different solutions. Threema Work is used by the Swiss government, Bosch, Daimler and others.

Threema and Matrix are quite different. Matrix is a centralized / federated system where data is stored on the server. Threema uses a decentralized protocol, where data and metadata (including groups) are stored on the devices only. This has advantages and disadvantages, depending on your requirements.

Yeah, but for less than 30k € you can already get a Renault Zoe with a speed of 145 km/h and a range of almost 400 km (52 kWh battery).

At the price of 50k €, you're in the Tesla Model 3 range.

Wow. For that price, you can easily buy an electric car.

Yep, I can totally relate. I found multiple bugs in a MessagePack JS implementation that were related to this issue.

I also worked on a project once where unique IDs of objects could get quite large (because they were random u64 integers). Those IDs were serialized and sent to a browser. Sometimes two objects were viewed as "the same" in the browser application because their IDs were truncated by the floating point precision issue.

Haha, yeah JS integers "can grow". Kind of. And then they bite you in the worst way possible. Especially when combined with cryptography (e.g. nonces).

Try this:

  >> const x = 288230376151711740;
  >> x == x + 1
  true

Or this:

  >> 2\*1024
  Infinity

JS doesn't even have integers. It only has floats. JS is by far the worst language I know of when it comes to integer support.

If you want a better example of arbitrary precision integers, try Python, for example.

Maybe give https://librepcb.org/ a try? The file format is optimized for version control. While it isn't yet as feature-rich as KiCAD yet (e.g. no differential pair length matching, no 3D preview) it tries to do better in terms of usability and library file format.

(Disclaimer: I'm a contributor)

The title is misleading, because defmt is not a debugger, but a logger (with a twist). A better title would be "Cheap Logging with Embedded Rust", or something like that.

The cool thing about defmt is that it doesn't do string formatting in the program itself. The problem with logging is that many formatting operations - like formatting floats as strings - can be very expensive on small embedded microcontrollers, both the runtime cost as well as a big increase in binary size. Instead, defmt sends the memory representation of the logged values to the host (over an arbitrary transport like UART or RTT). The formatting / visualization of the logs is then handled on the host side.

This has the downside that you cannot simply connect a random serial console to your microcontroller for logging, because defmt uses its own non-plaintext format. But it has the huge advantage that you can do very efficient logging in the microcontroller firmware, and then visualize all those logs on your host with an appropriate client.

More details can be found in the article itself.

They will still work.

This is what reproducible builds try to fix: https://wiki.debian.org/ReproducibleBuilds

This is mostly about updates (TOFU): If the OS installs the update, then you know it comes from the same developer.

Post-build modifications are the whole point of App Bundles :) See https://developer.android.com/platform/technology/app-bundle... for details.

In the case of Debian and F-Droid, they do so transparently, often with reproducible builds. The fact that packages are signed by those groups is one of the reasons why they are trusted. I would not consider "signed automatically by Google" to be an improvement in trustworthiness.

In the case of Apple, I agree. It doesn't make sense to use their ecosystem without trusting them fully.

However, in the case of Android / Google Play, right now the developers have the option to choose between APKs and App Bundles. Why take away that choice? If App Bundles are superior, then developers will choose that option freely. (Google Play is already really pushy when recommending to use App Bundles.)

Can it? Does it run with root permissions? (Honest question, I don't know.)

If it's bound by the OS permission system and doesn't have full root, it might be able to replace apps with another version that is signed by a different key (using the "programmatic app installing" permission). However, that would wipe the app data and break app updates. Not even adb can replace an app with one that is signed by a different key without data loss (adb install -r). And I'm sure a lot of developers ask for this feature.

The keys aren't surfaced, but a TOFU (trust on first use) model applies. If a new APK is signed by a different signing key, the OS will reject the update. To my knowledge, the only way to force-install an update signed with a new signing key would be to uninstall-and-reinstall the app. (This is what "adb install -r" does.) This will result in the loss of all app data.

Yup, I'm pretty sure this makes reproducible builds totally impractical for any apps installed through the Play Store.

Apps that currently provide reproducible builds: Signal, Threema, Telegram. (Probably others as well.)

In contrast to Omnisec and Crypto AG with their security by obscurity, the Threema apps are fully open source with reproducible builds: https://threema.ch/en/open-source/

> 2) No emoji colors

Colored emoji are working fine in my alacritty terminal. Here's my fontconfig file: https://github.com/dbrgn/dotfiles/blob/master/fonts.conf

Yes, it's very simplistic. It does not claim otherwise.

However, it did manage to detect a rootkit on one of my system once (many years ago, when I used to phpMyAdmin, which had some kind of RCE). So it's better than nothing, and it would probably have detected the backdoor from the article (which does not even attempt to hide itself).

This is called the "RAS Syndrome" (where "RAS" stands for "redundant acronym syndrome"): https://en.wikipedia.org/wiki/RAS_syndrome

rkhunter and samhain are two other similar tools. Both are available in the regular Debian repositories.

> But any dynamically fetched code/modules/packages will suffer the same risk.

A package manager usually employs signatures. In that case, the problem could have been avoided (unless the signing process itself is also compromised, then you're out of luck).

How would they do that? The bash script is a static file on a public host. Users can simply download it, without Codecov knowing about the repos it's being used in.

Never automatically download any remote code without at least checking the checksum.

Public key signatures would be even better. Then you only need to install / audit / trust the public key once, versus updating the checksum for every new release. Of course, this assumes that signing isn't compromised too, if that's the case then you're pretty much out of luck since a malicious release would be superficially indistinguishible from a real release.

There's a Rust RFC and Linus doesn't hate it. Great news!

There are a lot of weird "clones". I wouldn't say that Matomo is a Google Analytics clone, until recently it didn't even have an import function. I wouldn't say that Bitwarden is a LastPass clone. It's simply a different end-to-end encrypted server based password manager, there are a few of them.

Note that Grammarly is essentially a keylogger. The content you're typing gets sent to their servers. It doesn't work like your typical client-side spellchecker.

Their business model may be OK, it's just something that you need to be aware of (and a lot of people I've talked to aren't).

From the privacy policy:

---

We collect this information as you use the Site, Software, and/or Services:

- User Content. This consists of all text, documents, or other content or information uploaded, entered, or otherwise transmitted by you in connection with your use of the Services and/or Software. For more information about how we care for and protect your User Content, please see our User Trust Guidelines.