@linux_mclinuxface@fosstodon.org2024-04-25 21:42:48
Do I know anyone involved with #Debian packaging?
@linux_mclinuxface@fosstodon.org2024-04-25 21:42:48
@unixviking@social.linux.pizza2024-04-23 16:27:38
@simon_brooke@mastodon.scot2024-05-24 09:06:30
@xtaran@chaos.social2024-05-15 22:42:52
Orphaned two of my #Debian packages today:
* #wicd: https://bugs.debian.org/1071199 (Upstream halfdead but h…
@xtaran@chaos.social2024-05-15 22:42:52
Orphaned two of my #Debian packages today:
* #wicd: https://bugs.debian.org/1071199 (Upstream halfdead but h…
@simon_brooke@mastodon.scot2024-04-11 14:36:25
#Debian 12 -- current stable -- provides Gradle 4.4.1. The current stable version of Gradle is 8.7.
Yes, the reason I choose and use Debian is because it is conservative, which means things don't break often. But that seems wildly out of date!
@alsutton@snapp.social2024-04-19 08:39:32
@Kencf618033@disabled.social2024-06-16 16:28:53
It lives...!
Reinstalled #MintLinux “Vera” from DVD, so #Debian (and any #ArchLinux adventures) are on hold for the duration.
@cdp1337@social.veraciousnetwork.com2024-06-12 02:29:37
Hmmm, anyone familiar with the internals of #Zabbix happen to know why the 7.0.0 repo doesn't support #RaspberryPi running #Debian 12 (bookworm)?
They hav…
@xtaran@chaos.social2024-04-04 07:36:32
Yay, #Debian reduces #OpenSSH dependencies (in Debian Unstable for now) and removes #libsystemd dependency.
openssh (1:9.7p1-4) unstable; urgency=medium
* Rework systemd readiness notification an…
@pusakat@mas.to2024-04-26 14:02:05
I'm starting work on migrating my personal workstations from the most popular Debian-based distro back to #Debian again. There will be some challenges, I'm sure. But it's been long in coming. For now, I'll be dual-booting until I've made sure that everything I had working in the old distro will work fine in #Debian12
@Kencf618033@disabled.social2024-06-16 23:30:52
I should clarify that I’d reinstalled #MintLinux on Blue 1T (secondary PC, which remains stubbornly off) and Black 1T (primary), which died running #Debian. Surprisingly Black 1T booted, the technician notwithstanding.
@CondeChocula@social.linux.pizza2024-05-01 17:40:50
Ohh lord, thanks to Timeshift I recovered my openbox session in Debian.
I went to spectrwm again but didn't conviced me then when I installed again Openbox the submenu piped in right click didn't work. :(
I had have to rollback.
#debian #timeshift
@stsquad@mastodon.org.uk2024-04-28 12:02:28
@Kencf618033@social.linux.pizza2024-03-26 11:02:21
@justpixel@social.linux.pizza2024-04-13 22:27:23
@simon_brooke@mastodon.scot2024-06-04 09:55:20
@Kencf618033@disabled.social2024-06-10 22:47:34
Dunno if I made the #ArchLinux thumb drive bootable. I’ve two computers I can’t turn on (marvelous me). Shall unplug the #Debian SSD, swap things.
@xtaran@chaos.social2024-05-06 01:11:18
@xtaran@chaos.social2024-05-05 12:07:58
Anyone has an idea why for a few weeks, the #ComposeKey under #X11 on #Debian Unstable (set via "setxkbmap -option compose:menu -option compose:rwin -option compose:rctrl -option compose:ralt") suddenly …
@galaxydinodragon@social.linux.pizza2024-03-26 16:59:12
@engerlost@social.linux.pizza2024-04-08 23:31:57
@xtaran@chaos.social2024-06-04 22:03:11
#BikeStreak, Day 65: After work from home I rode to the #Debian meetup at the https://dapizi2017.ch/ restaurant in Zu…
@schrht@social.linux.pizza2024-06-05 08:14:59
I have a machine in #VirtualBox (VirtualBox 7.0, #Debian 12) that randomly freezes for no discernible reason - most of the times it happens after a few minutes of operation, with no significant load. I also can't shut down the virtual machine (process goes into overdrive gobbling up CPU)…
@xtaran@chaos.social2024-06-04 22:03:11
#BikeStreak, Day 65: After work from home I rode to the #Debian meetup at the https://dapizi2017.ch/ restaurant in Zu…
@Kencf618033@disabled.social2024-03-26 15:30:25
•••my new best friend is deborphan #Debian #Linux
•••I don’t think Baltimore has been in the news since The Wire went off the air. Major, major infrastructure clusterfuck.
#KeyBridgeCollapse
@Xavier@infosec.exchange2024-03-31 23:15:39
@rene_mobile@infosec.exchange2024-03-30 21:58:50
My current take on the #xz situation, not having read the actual source backdoor commits yet (thanks a lot #Github for hiding the evidence at this point...) besides reading what others have written about it (cf. #rustlang for such central library dependencies would maybe (really big maybe) have made it a bit harder to push a backdoor like this because - if and only if the safety features are used idiomatically in an open source project - reasonably looking code is (a bit?) more limited in the sneaky behavior it could include. We should still very much use those languages over C/C for infrastructure code because the much larger class of unintentional bugs is significantly mitigated, but I believe (without data to back it up) that even such "bugdoor" type changes will be harder to execute. However, given the sophistication in this case, it may not have helped at all. The attacker(s) have shown to be clever enough.
6. Sandboxing library code may have helped - as the attacker(s) explicitly disabled e.g. landlock, that might already have had some impact. We should create better tooling to make it much easier to link to infrastructure libraries in a sandboxed way (although that will have performance implications in many cases).
7. Automatic reproducible builds verification would have mitigated this particular vector of backdoor distribution, and the Debian team seems to be using the reproducibility advances of the last decade to verify/rebuild the build servers. We should build library and infrastructure code in a fully reproducible manner *and* automatically verify it, e.g. with added transparency logs for both source and binary artefacts. In general, it does however not prevent this kind of supply chain attack that directly targets source code at the "leaf" projects in Git commits.
8. Verifying the real-life identity of contributors to open source projects is hard and a difficult trade-off. Something similar to the #Debian #OpenPGP #web-of-trust would potentially have mitigated this style of attack somewhat, but with a different trade-off. We might have to think much harder about trust in individual accounts, and for some projects requiring a link to a real-world country-issued ID document may be the right balance (for others it wouldn't work). That is neither an easy nor a quick path, though. Also note that sophisticated nation state attackers will probably not have a problem procuring "good" fake IDs. It might still raise the bar, though.
9. What happened here seems clearly criminal - at least under my IANAL naive understanding of EU criminal law. There was clear intent to cause harm, and that makes the specific method less important. The legal system should also be able to help in mitigating supply chain attacks; not in preventing them, but in making them more costly if attackers can be tracked down (this is difficult in itself, see point 8) and face risk of punishment after the fact.
H/T @… @… @… @… @…
@xtaran@chaos.social2024-04-02 20:32:31
#30DaysOfBiking, Day Two: A Triangle
Normal morning commute.
In the early evening cycling over #Bucheggplatz and Kornhausbrücke towards Josefstrasse for the #Debian Switzerland
@Xavier@infosec.exchange2024-03-31 23:15:39
@rene_mobile@infosec.exchange2024-03-30 21:58:50
My current take on the #xz situation, not having read the actual source backdoor commits yet (thanks a lot #Github for hiding the evidence at this point...) besides reading what others have written about it (cf. #rustlang for such central library dependencies would maybe (really big maybe) have made it a bit harder to push a backdoor like this because - if and only if the safety features are used idiomatically in an open source project - reasonably looking code is (a bit?) more limited in the sneaky behavior it could include. We should still very much use those languages over C/C for infrastructure code because the much larger class of unintentional bugs is significantly mitigated, but I believe (without data to back it up) that even such "bugdoor" type changes will be harder to execute. However, given the sophistication in this case, it may not have helped at all. The attacker(s) have shown to be clever enough.
6. Sandboxing library code may have helped - as the attacker(s) explicitly disabled e.g. landlock, that might already have had some impact. We should create better tooling to make it much easier to link to infrastructure libraries in a sandboxed way (although that will have performance implications in many cases).
7. Automatic reproducible builds verification would have mitigated this particular vector of backdoor distribution, and the Debian team seems to be using the reproducibility advances of the last decade to verify/rebuild the build servers. We should build library and infrastructure code in a fully reproducible manner *and* automatically verify it, e.g. with added transparency logs for both source and binary artefacts. In general, it does however not prevent this kind of supply chain attack that directly targets source code at the "leaf" projects in Git commits.
8. Verifying the real-life identity of contributors to open source projects is hard and a difficult trade-off. Something similar to the #Debian #OpenPGP #web-of-trust would potentially have mitigated this style of attack somewhat, but with a different trade-off. We might have to think much harder about trust in individual accounts, and for some projects requiring a link to a real-world country-issued ID document may be the right balance (for others it wouldn't work). That is neither an easy nor a quick path, though. Also note that sophisticated nation state attackers will probably not have a problem procuring "good" fake IDs. It might still raise the bar, though.
9. What happened here seems clearly criminal - at least under my IANAL naive understanding of EU criminal law. There was clear intent to cause harm, and that makes the specific method less important. The legal system should also be able to help in mitigating supply chain attacks; not in preventing them, but in making them more costly if attackers can be tracked down (this is difficult in itself, see point 8) and face risk of punishment after the fact.
H/T @… @… @… @… @…