How do you get one step ahead of that? Does the community focusing on SSHD impact some other part of the system as a whole? Some other technological aspect? Social?
Tin foil hats are fun!
IME/IIRC There aren't (or shouldn't be) any binary contents on Flathub that are submitted by the author, at least for projects with source available? You're supposed to submit a short, plain-text recipe instead, which then gets automatically built from source outside the control of the author.
> The Flathub service then uses the manifest from your repository to continuously build and distribute your application on every commit.
https://docs.flathub.org/docs/for-app-authors/submission/#ho...
Usually the recipes should just list the appropriate Git-based URLs to get the source code, or, for proprietary applications, the official .DEBs. Kinda like AUR, but JSON/YAML. Easy to audit if you want:
https://github.com/orgs/flathub/repositories
Plus, if properly configured, Flatpak is supposed to securely sandbox every application anyway, although other systems it needs to be compatible with (E.G. X11) currently prevent that.
And then the frequent use of git submodules makes it even worse: that's often a whole lot of code that even the author of the flatpak doesn't have control over.
The JSON manifest is a much smaller attack surface than uploading random binaries would be though. And the standardized build procedure should make it relatively easy to tell if something's out of the ordinary and should be raising eyebrows, or even automate much of it.
Maybe stick an `alias CheckFlatHub=` for a LLM prompt, or just some plain regexes, in `.bashrc`? Looking for fishing URLs and install commands sounds like a relatively simple problem, as far as security challenges go.
In fact we already have a very good solution, and it's simply the infrastructure of a typical Linux distro (replicated by package managers on other systems, such as F-Droid). It's quite an impressive feat really - a diaspora of independently trusted organizations, each with their own governance structures and PGP-enforced webs-of-trust, crafting public repositories of known-good software built from publicly published source code using publicly published build scripts, delivered to the user over strong encryption. On the whole this does an incredible job of keeping malicious or subversive software out, and we've all got so comfortable with just being able to "apt-get install <foo>" without worrying about malware that we've forgotten what a dangerous business running software from the internet used to be.
Which is why this xz attack is so unusual and surprising - it's like the police stopping an attempted murder in the nick of time in a sleepy crime-free town. As shocking as it is, we must ignore the cries of "something must be done" and resist the temptation to put up barbed wire fences all over our nice town.
For example, Ubuntu 24.04 will ship without Deno. It will also ship with Cargo 1.75, which is too old to build Deno (there's some weird packaging issue). So, anybody who wants Deno on Ubuntu has to install it using either `curl | bash`, nix (which of course seems promising), or asdf (which I know nothing about). Most devs would choose curl|bash.
Why is Deno not packaged for Ubuntu/Debian? Because it's "hard", and it's hard in different ways for different distros (the debian ticket for this has sat without action for 2-3 years, and I think the Deno ticket a similar amount of time). Cross-distro solutions like flatpak (or nix) are 100% necessary if we are to get rid of curl|bash. But, the sandboxing story with flatpak/snap is currently pretty bad; apps just fail in mysterious ways if they try to access resources they're not allowed access to. Nobody wants Windows Vista, but it has been done reasonably well in various other OSes.
That's a feature. I don't want anything bleeding edge. Give me older battle tested to hell and back code. Nothing new.
[1] https://github.com/tukaani-project/xz/commit/780d2c236de0e47...
Or buy closed source from someone like Microsoft, hoping that they have the resources and actually use the resources to scrutinise code more vigorously.
And there is always the approach of having a great secops team to detect strange network activity and attempts to escalate.
But from contributors who have no history and no footprint other then the project they're working on. That should be a red flag in the future.
The old groups GOBBLES,ADM,ac1db1tch3z,~el8 were doing it, private "security researchers" like isec.pl were doing it.
This time it's a problem because state actors are abusing the corporate capitalism that created this era of underpaid people working on foundational projects. The bad actors have unlimited resources for their objectives.
That's basically what created the demand and ineption of groups like NSO,Zerodium etc..
Basically before that exploits and backdoors were worthless and hackers hoped to be sponsored or hired by companies like Qualys.
And I don't see what money has to do with any of this. There could be some well-paid programmer slipping backdoors into proprietary code just as easily. The salary or openness didn't affect the outcome. It's just as easy for salaried programmers to betray their bosses and their users.
2. Stop accepting shit tools like M4 and C for creating any software.
You can never make the work of black hats impossible but you can trivially make it a whole lot harder.
---
> You:
> Below is a hexdump of a test file added to our code repository. Is it any cause for concern?
```
0000000 375 7 z X Z \0 \0 004 346 326 264 F 002 \0 ! 001
0000010 \b \0 \0 \0 330 017 # 023 001 \0 \f # # # # H
0000020 e l l o # # # # \0 \0 \0 \0 022 210 337 004
0000030 Y r 201 B \0 001 % \r q 031 304 266 037 266 363 }
0000040 001 \0 \0 \0 \0 004 Y Z 375 7 z X Z \0 \0 004
0000050 346 326 264 F 002 \0 ! 001 \b \0 \0 \0 330 017 # 023
0000060 340 005 026 001 _ ] \0 005 245 - U 273 230 004 |
0000070 306 231 274 240 f M 315 1 255 \v ) 270 ( \f .
0000080 274 3 263 ~ * 323 312 n 324 C 034 Q Y 314 217 341
0000090 350 343 357 @ 227 271 247 w 026 255 237 U * H 367 240
00000a0 K 260 p 9 5 370 j 017 203 ? 307 ] 005 326 220 240
00000b0 352 I 236 ` ? 304 306 365 246 375 226 [ 257 a 177 -
00000c0 261 033 204 001 203 251 346 252 243 244 < 016 h 256 273 356
00000d0 320 206 ! 355 367 P ) 247 035 226 357 026 224 324 u K
00000e0 255 8 277 326 350 347 205 \n : 220 334 342 u 216 M 357
00000f0 \f = c 316 244 % \0 233 E 354 x " 376 250 266 247
0000100 ^ 303 S 273 220 271 0 | 232 222 252 033 251 \r 372 g
0000110 n 221 177 ) 270 l \v X 315 w , ( \t 254 * $
0000120 023 031 ! | 003 J 0 262 002 030 230 321 4
0000130 340 233 216 337 360 261 \ ] 216 016 020 206 001 357 346 332
0000140 337 z 306 363 374 ] 354 323 335 [ 337 214 z 330 226 027
0000150 j 255 037 260 ' 027 356 333 F W V 200 030 H ; 337
0000160 \n 245 q 7 372 360 I 263 ; 326 316 321 306 030 q K
0000170 337 264 030 1 345 z 032 @ 357 301 ] 302 U < 037 262
0000180 363 272 241 231 346 s \0 337 216 235 375 236 [ 037 215 037
0000190 274 341 033 200 \0 \0 \0 \0 u 216 336 U 336 r 1 u
00001a0 \0 001 311 002 227 \n \0 \0 \n 224 r 242 261 304 g 373
00001b0 002 \0 \0 \0 \0 004 Y Z 375 7 z X Z \0 \0 004
00001c0 346 326 264 F 002 \0 ! 001 \b \0 \0 \0 330 017 # 023
00001d0 001 \0 \r # # # # W o r l d # # # #
00001e0 \n \0 \0 \0 x 360 \v ) 314 g 337 330 \0 001 & 016
00001f0 \b 033 340 004 037 266 363 } 001 \0 \0 \0 \0 004 Y Z
0000200
```
> The hexdump you've provided appears to be a binary file. It's difficult to determine if it's a cause for concern just by looking at the hexdump. Here are a few things you could consider:
> 1. *File Origin*: If this file was added by a trusted team member and it's expected to be part of your code repository, it's probably safe. If the file's origin is unknown or it was added unexpectedly, you might want to investigate further.
> 2. *File Purpose*: Understanding what this file is used for can help determine if it's a cause for concern. If it's a binary used for testing or a necessary part of your application, it might be fine. If its purpose is unclear, it's worth checking.
> 3. *File Analysis*: You could use file analysis tools to examine the binary file. This could provide information about what the file does, which can help you decide if it's a cause for concern.
> 4. *Security Scans*: Consider running security scans on the file. There are many tools available that can scan binary files for known security vulnerabilities.
> 5. *Code Review*: If this file was added as part of a commit, make sure the commit was reviewed thoroughly. Unexpected binary files can sometimes be a sign of an insecure direct object reference (IDOR) vulnerability.
> Remember, when in doubt, it's always better to err on the side of caution. If you're unsure, consider reaching out to a security professional. They can help you analyze the file and determine if it poses any risk.
Lol.
---
> 2. Stop accepting shit tools like M4 and C for creating any software.
> You can never make the work of black hats impossible but you can trivially make it a whole lot harder.
What could be more trivially done than simply replacing C for all code?