Announcement

Collapse
No announcement yet.

Devuan 2.1 Released - Still Delivering Debian 9 Without Systemd

Collapse
X
 
  • Filter
  • Time
  • Show
Clear All
new posts

  • #61
    Originally posted by aht0 View Post
    If you look upwards and read it over again word-by-word, you'll notice it wasn't quite what I said. There was one important conditional altering the meaning subtly. I wasn't using 'when' there, I used 'if'. Which shows I considered it as probability, not quaranteed when.
    What you said is still wrong. First, using breakable crypto is just that, breakable crypto. It's still crypto. Second, you do not know if journald's crypto is breakable. Third, you know about such thing as "editorial synthesis"? You may not have said that "journald log sealing is security by obscurity", but you strongly hint at that. Which is false.

    Originally posted by aht0 View Post
    Potential weakness(es) in algorithm(s), weak key(s), programming error(s) [which are quaranteed to happen]
    Programming errors can happen in any software. Potential weaknesses can happen in any invented algorithm. You cannot use "what-ifs" as a valid criticism.

    Originally posted by aht0 View Post
    brute force attacks using quantum computers - uhm, can you claim forward-sealing to be quantum-safe? If not then applying quantum computing means that crypto might as well not be there at all.
    Again, wrong. You cannot judge an algorithm by its resilience to yet-unknown or yet-impossible types of attacks. "What if there was an attack that breaks all known crypto? Then all known crypto is worthless, uh-oh!" It's an unproductive way to lead a discussion. There are no known attacks on journald log sealing, period.

    Originally posted by aht0 View Post
    Intelligence agencies (at least U.S and Chinese should have quantum computing capability for some time now, considering that first models have been reaching public over the past few years, tech available for intelligence is generally well-ahead of what could be available for public even for obscene amount of money)
    I'll give you fun fact: who's RHEL's largest customer?: U.S military-industrial/government complex. Verified by US Army's Maj.General Nicholas Justice, who happened to come public with that tidbit of information.
    <tinfoiling skipped>

    Originally posted by aht0 View Post
    But then we may see some new CVE's, which would allow attacker to crash systemd component(s) and achieve priv.escalation. Let's recall CVE-2018-16864, CVE-2018-16865 and CVE-2018-16866. Quite recent actually (less than a year). These caused systemd-journald ITSELF to crash and enabled takeover of a system.
    Vulns happen.

    If anything, then systemd is significantly better protected against vulnerabilities than absolute majority of other software out there. See all those settings in journald's unit file? journald is sandboxed to hell and back. I'm not even sure if those CVEs are actually exploitable.

    Originally posted by aht0 View Post
    My preferred approach would be "less code, less feature creep".
    Let's just throw out computers? No code, no vulnerabilities possible whatsoever. You see, all that code actually does useful things. If you throw out some code from systemd, you will have to add it back somewhere.

    Originally posted by aht0 View Post
    systemd is actually awesome idea but it's design and implementation have proven to be disgusting show of "let's try this & we know better & this is feature not a bug & we won't fix".
    Are we still talking about security or you're just venting at this point that systemd closed your favorite bug as WONTFIX? And yes, what's wrong with design of systemd? Point by point.

    Originally posted by aht0 View Post
    Yes. But once it was presented as an argument supposedly proving systemd's inherent superiority, it had to be dissected at length, right?
    I don't know anything about "inherent" superiority. Log sealing is just a secondary feature in one of the optional components of the systemd suite. And yes, I'm all for dissecting at length, but the quality of your dissection is honestly lacking.

    Comment

    Working...
    X