khayyam wrote:depontius ... yes, that's the subject of the link I provided (above). The interesting part of it is how it was suggested they aquire the firmware, if the company wants government contracts then the source code needs to be handed over for 'auditing'.depontius wrote:And in fact, in recent news there's talk about the NSA getting something stuffed in hard drive firmware.
Yeah, I think I read this some 6 to 8 months back ... the problem is, you've got bios/uefi, usb, etc, etc ... so any number of other possible modes of entry.depontius wrote:On the same topic, I've seen stuff on the web about some guy who disassembles and is working at replacing hard drive firmware.
best ... khay
NSA-Linked Spyware Found in Hard Drives WorldwideNSA-Linked Spyware Found in Hard Drives Worldwide wrote:The new platforms, which appear to have been developed in succession with each one surpassing the previous in sophistication, can give the attackers complete and persistent control of infected systems for years, allowing them to siphon data and monitor activities while using complex encryption schemes and other sophisticated methods to avoid detection. The platforms also include an innovative module, the likes of which Kaspersky has never seen before, that re-flashes or reprograms a hard drive’s firmware with malicious code to turn the computer into a slave of the attackers.

Interesting. Also saw this article in today's e-newspaper:tclover wrote:NSA-Linked Spyware Found in Hard Drives Worldwide
Come on, nobody would be surprised by _actual_ (NSA) "auditings" these days. (And some morrons should stop saying "HDD manufacturers refuse to say if they received a... letter/request." Change the program! that one is too old, dammit.) And _he_ wouldn't be surprised either... for sure. If he's not using M$ OS[+TrueCrypt] (as this seems to be the _implicit_ target here) at the moment, he should concentrate a bit more on D-Bus & crap Kit before it's too late. (Well, he might concentrate on sysd if he switched.)krinn wrote:Guys, you should stop posting links like these ones, if miroR read this thread, it might be too much for his heart.
http://www.theguardian.com/technology/2 ... mised-firmFitzcarraldo wrote:Interesting. Also saw this article in today's e-newspaper:
Sim card database hack gave US and UK spies access to billions of cellphones
Big Brother is watching humanity.
Proinsias wrote:http://www.theguardian.com/technology/2 ... mised-firmFitzcarraldo wrote:Interesting. Also saw this article in today's e-newspaper:
Sim card database hack gave US and UK spies access to billions of cellphones
Big Brother is watching humanity.
[Credit: about 3 comments down on that Guardian article, as expected]me wrote:Well, they would say that, wouldn't they?

Havin_it wrote:Well, they would say that, wouldn't they?
[Credit: about 3 comments down on that Guardian article, as expected]

HAL was removed from the latest Xorg (at least for x86 platforms), so you shouldn't need to enable hald or dbus anymore. You need to enable vt to run X.truekaiser wrote:I would like to add that this subject has at least prompted me to try bsd. Which failed spectacularly when I installed xorg without hal support(it's still needed in bsd land) and well.. their package management system won't let me reinstall it..
Code: Select all
In loader.conf(5):
hw.vga.textmode=1
kern.vty=vtFor a while a couple of years ago I delved into Solid (the KDE device-abstraction component) in order to find a way to make it decouple from udisks and upower and thereby from Polkit. I managed to get partway free, but the results were still not as happy as I would want. After all, since KDE targets multiple OS's, including Windows, there *has* to be a way to change out those lower layers. I was aiming to make a newer lower level, selectable by USE flag, to select the non-kit interface layer. Unfortunately, I ran out of time before I could get it all figured out. I did not quite get the hang of the build system, nor did I get completely clear on what was making setup calls to Polkit even though the lower-level code wasn't going through Polkit any more. The fact that build times were so long did not help matters. If I had more time to do it, I think I could have gotten it worked out.onimeno wrote:After 13 years of daily Gentoo use, I finally got around to making a forum account just to say - How can I help?
I recently purged my system of *kit, dbus, avahi, pulseaudio, zeroconf, udev->eudev and anything else belonging to that cult.
Everything still seems to work fine, which leaves me confused as to why KDE insists it really needs consolekit and polkit for whatever reason. Needless to say my emerge -u world does not work as of yet.
Would that be a good place to start? Ie, remove the hard dependency on consolekit/polkit in one of the kdm dependencies (forget which at the moment). Apologies if this has been asked before.
I'm a developer by trade and very eager to contribute back to my OS of choice to ensure that it remains pro-choice.
PS - That first sentence makes me feel old.
onimeno wrote:After 13 years of daily Gentoo use, I finally got around to making a forum account just to say - How can I help?
I recently purged my system of *kit, dbus, avahi, pulseaudio, zeroconf, udev->eudev and anything else belonging to that cult.
Everything still seems to work fine, which leaves me confused as to why KDE insists it really needs consolekit and polkit for whatever reason. Needless to say my emerge -u world does not work as of yet.
Would that be a good place to start? Ie, remove the hard dependency on consolekit/polkit in one of the kdm dependencies (forget which at the moment). Apologies if this has been asked before.
I'm a developer by trade and very eager to contribute back to my OS of choice to ensure that it remains pro-choice.
PS - That first sentence makes me feel old.

Systemd has nothing to do with Gnome and KDE so far.peter-dambier wrote:Running without gnome and kde may be the reason why systemd did not work for me.
I'm using for ages Englightenment e16. Ok, my login manager is kdm. But I don't have any Gnome stuff installed. At least e16 doesn't have any Gnome dependency.peter-dambier wrote:Last time I used enlightenment as my desktop. I am afraid enlightenment does need too much gnome stuff.
E17+ does not as well, there is no hard dependency to GNOME stuff. Although E18+[wayland,drm] require logind... Choose wisely, or rule 'em out. Perfectly satisfied with E18[X,opengl] first after a slightly bothersome E17[X,opengl] upgrade; and then recently to E19[opengl]. Everything looks fine but a little issue with tray-icon... XEmbed is planned to be removed in favor to libindicator. I knew this already for months... still need XEmbed for ladi-system-tray mainly (and dhcpcd-ui in a minor extend.) Still workable with an awfull notification area... Still, almost all major DE are moving to libindicator, nothing surprising. As the move to SystemD. Still Enlightenment is on the move for wayland/drm rendering engines (logind dep.)musv wrote:I'm using for ages Englightenment e16. Ok, my login manager is kdm. But I don't have any Gnome stuff installed. At least e16 doesn't have any Gnome dependency.
If it helps I am using plasma 5.3.1 from the kde-overlay and things are still working great with KDE. So we're probably okay at least for another couple years or so.augustin wrote:
I personally am still worried about KDE, my DE of choice. I wonder how much longer I'll be able to use it without systemd and logind. I don't know of any wiki page that details any of this.
why bother? the API will just change again to ensure nobody ever gets to catch up... systemd exists primarily for the purpose of vendor lock in, not to solve technical problems.genstorm wrote:The one from Canonical? I thought that was pretty much dead after some systemd changes. Someone needs to write an alternative logind implementation...depontius wrote:There is a systemd-logind shim somewhere out there.
You know, if I were retired I think I'd take it on. It would be kind of fun writing systemd-shims, just to make them keep changing their stuf, and drive them a little nuts. I'd also be doing a public service, not with the shims, but by exposing their reactions.saellaven wrote:why bother? the API will just change again to ensure nobody ever gets to catch up... systemd exists primarily for the purpose of vendor lock in, not to solve technical problems.genstorm wrote:The one from Canonical? I thought that was pretty much dead after some systemd changes. Someone needs to write an alternative logind implementation...depontius wrote:There is a systemd-logind shim somewhere out there.