Announcement

Collapse
No announcement yet.

Fedora Moves Ahead With Plans To Drop Packages Having Bad Security Practices

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

  • #11
    Originally posted by Weasel View Post
    snip... drivel
    Removing software that isn't receiving security fixes is a solution, not a problem. Clearly Microsoft has a different approach, which is one of the reasons they're losing.

    Comment


    • #12
      Originally posted by Weasel View Post
      See guys?
      Nope, not gonna happen, because of ELF. Running Reaper in Wine solves this completely. Windows has no such issue, neither does Wine, because they both use something sane called PE/COFF/DLLs.

      There's nothing flatpak can do about it. At this point, ELF needs to get scrapped and Linux either needs to support DLLs, or FORCEFULLY demand that all libraries use symbol versioning.
      They also need to support DLL Hell

      Comment


      • #13
        Originally posted by onicsis View Post

        They also need to support DLL Hell
        For fuck's sake dude, ELF suffers from the same thing, as does any library format. Do you guys even understand shit you link to?

        I know I'm overly aggressive here but I'm sick of people linking that exact same thing everytime they see the word "DLL". DLL Hell is just a term and misleading for clueless muppets: every fucking library format suffers from it, since it's about the design of the library itself (i.e. the library developer).

        Either that, or 16-bit Windows where DLLs were loaded in in the same address space. Which is irrelevant. Do you see 16-bit ELF around? No, so shut the hell up, nobody was talking about it.

        It's probably called DLL Hell because nobody else gives a shit about the other shit-tier formats like ELF, and it sounds better than "Dependency Hell".

        Comment


        • #14
          Originally posted by mulenmar View Post
          First time I've ever seen DLLs called "sane".
          Time to pop that bubble then. UEFI uses it too, so technically even your PC does. Get mad now.

          Originally posted by FishB8 View Post
          This is so warped, delusional, and misinformed that all I can do is roll my eyes and move on.
          I've something to tell you. A very large secret, that will answer deep questions about the Universe.





          Ignorance is not bliss. Stop it.

          Comment


          • #15
            Originally posted by JanC View Post
            You don't need Flatpak or Snap or some other similar technology to distribute your own software, you can do that using the existing package management systems, and several software projects have been doing that for a very long time.
            That doesn't solve the problem I was describing in the slightest either.

            Originally posted by JanC View Post
            This has nothing to do with ELF vs. PE/COFF.
            Fedora drops packages -> you need flatpak to solve this situation -> even flatpak can't solve ELF's serious issues.

            So yeah, a lot to do with it.

            Originally posted by JanC View Post
            Also, why does Reaper let plugins load/use their own GUI library into the same process? That seems like a bad design…
            Bad design? That's exactly what plugins are. They rely on the VST SDK for example, which defines an audio interface. That's it.

            Plugins obviously need a GUI and a toolkit, which is totally separate from the VST spec (they can do what they want you know).

            What the hell do you want a plugin SDK to embed its own entire graphical toolkit or what? Only to support shit-tier design like ELF with its "global namespace" which is the source of all this trouble.

            Cause DLLs have no issues whatsoever loading 100 different versions of the same toolkit, since each symbol is local to the module.

            Using ELF is like using short-named global variables in your code with no prefix and no namespaces whatsoever. Retarded crap.

            Comment


            • #16
              Originally posted by Weasel View Post
              Cause DLLs have no issues whatsoever loading 100 different versions of the same toolkit, since each symbol is local to the module.
              This may be why SFML and Cubeb are segfaulting in my project when statically linked: two different versions of pthread causing conflict...?

              Comment


              • #17
                Originally posted by Weasel View Post
                No, it's not about these packages and it's not about the security implications at all that I'm speaking about. It's a far broader point: packages of your application (basically, your app's distribution itself) get dropped at the decision of someone else. That's why it's not sane and no dev wants it.
                That's fine from the perspective of a developer who just wants to put their software out there and doesn't care about impacts on users. It's pretty easy to turn your argument around simply by looking from the user perspective. If you depend solely on upstream packages, there's no consistent expectation of sane ecurity policy. See https://access.redhat.com/security/updates/classification for the definitions of "IMPORTANT" and "CRITICAL" — this is not arbitrary and the policy we're enacting here seems completely reasonable.

                There definitely *are* problems with distro packaging, but this ain't one of 'em.

                Comment


                • #18
                  Originally posted by mattdm View Post
                  That's fine from the perspective of a developer who just wants to put their software out there and doesn't care about impacts on users. It's pretty easy to turn your argument around simply by looking from the user perspective. If you depend solely on upstream packages, there's no consistent expectation of sane ecurity policy. See https://access.redhat.com/security/updates/classification for the definitions of "IMPORTANT" and "CRITICAL" — this is not arbitrary and the policy we're enacting here seems completely reasonable.

                  There definitely *are* problems with distro packaging, but this ain't one of 'em.
                  Nope, it doesn't matter how flawed the application is. I never said you have to hide its security implication. Heck, make it an extra step to get if someone actually wants it. By no means did I want it "as default".

                  Maybe stop treating users like children that need to be taken care of under any circumstances. The defaults can be that way, but if someone who really doesn't care about the security implications (maybe he even wants to run it in a VM?) wants to get it, he won't be able to, as if telling him "you don't know what you want, I know better". That is what's wrong with distro packaging.

                  It's not just distro packaging btw. It's the same thing with centralized crappy stores like in iOS or Microsoft Store or Google Play or w/e. I hate them all equally.

                  Saying stuff like "nobody will want to download such XYZ application riddled with ABC with good conscience" or whatever other patronizing argument is just proven wrong so many times, just look even at "dead" software it still gets downloads or people who go the extra mile trying to find it. Not only do they know what they're doing, they even go to painstaking lengths to get it.

                  Note that I'm not saying that distros have to package everything. I just find the whole centralized packaging concept flawed, hence my first post where it was a perfect proof for people who really don't know why it's lacking (because they never needed the "extra mile"). So it's a good use-case for flatpak.
                  Weasel
                  Senior Member
                  Last edited by Weasel; 31 August 2018, 02:26 PM.

                  Comment


                  • #19
                    I don't think you're getting what distro packaginge is, at least in Fedora (and in the ideal). No one is forcing you to use distro packages — you can build yourself, or get from the upstream or vendor in whatever form they provide. But if it's part of the Fedora package collection, you can expect it to be built in a certain way (with compiler-hardening flags, for example), that the license is free and open source, and that, yeah, someone is watching out for security issues. If we can't keep up with that for a particular package, it shouldn't be in the collection

                    Comment


                    • #20
                      If distro packagers didn't do this, we'd be like Windows, where local admins need to manage every piece of software by hand. That's exactly the worst thing about Windows. As mattdm says, you're free to do that with any Linux distro (maintain your own repo and don't use distro repos at all, or worse, micro-manage packages on each machine), it's just that nobody wants to because it's insane.

                      Comment

                      Working...
                      X