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

  • JanC
    replied
    I explained why there is no problem with the ELF format, and where the problem(s) likely are, but if you want to ignore people trying to help you, feel free…

    Leave a comment:


  • Weasel
    replied
    Originally posted by JanC View Post
    If your (in-process) plugins need a GUI, it might be a good idea to provide or mandate an API for that, so that they look and work somewhat the same as your application. Providing a GUI abstraction layer would also make it a lot easier to port plugins between various platforms (no need to write a new GUI for each of them).

    But of course nobody ever said the VST spec/SDK is sane in that regard (it was never designed to be cross-platform, I suppose).
    It works on Mac and Windows so it's pretty cross platform I guess. (it even works on Linux, albeit with those problems due to ELF)

    Also you seem to be missing the point here. Plugins are not always tied to an application. In the VST case, you don't write plugins for REAPER, you write plugins for the VST interface. An application, such as REAPER, can be a VST host and implement the hosting interface. There are a LOT of VST hosts out there.

    People need to stop this mentality that plugins need to be written only for a specific application. No, plugins need to be written for a specific interface and then they work for ALL applications that implement such interface.

    On a sidenote: VST is a garbage interface, but there are other interfaces out there which exhibit the same problems only on ELF. VST2 is however, for some reason, the most popular by far and wide, so I used it as an example.

    Originally posted by JanC View Post
    ELF supports versioned symbols and such, but the default shared library loader does not use them, and by default most linkers don't create them. In any case, it's up to the application loading them to ask for it; I'm pretty sure neither Reaper nor the plugins do that. It's up to the library provider to support it. And I suppose the VST spec and/or SDK don't have provisions for this.

    There is also another issue: I'm not sure Gtk itself would like that, because of the way it implements its main loop etc., so sharing Gtk 2 & 3 in one application might fail even on Windows (but I didn't test that, so it's just a guess, and it might depend on what features you try to use, as Gtk is more than just a GUI library).
    But symbol versioning should be *enforced* by the loader, or by the format itself. For example, with DLLs, it is literally impossible to import a symbol without specifying the module for it. As in, impossible from a format standpoint (which is really what this is about). I think it's similar with Mach-O. That's why ELF sucks.

    Originally posted by JanC View Post
    Another solution might be to use out-of-process plugins, of course, but those might come with their own issues (especially on Windows?).
    Out-of-process actually sounds like there should be no problems neither on Linux/ELF and Windows. It's a known hack around shitty plugins coded with global variables that can't run in more than one thread.


    Note that it's not Linux's fault per se. Reaper in Wine works just fine. It's not a problem in Linux itself. It's a problem with the ELF format and the loader. I never said you can't have a sane environment on Linux. That sane environment is called Wine. ;-)

    Leave a comment:


  • JanC
    replied
    Originally posted by Weasel View Post
    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).
    If your (in-process) plugins need a GUI, it might be a good idea to provide or mandate an API for that, so that they look and work somewhat the same as your application. Providing a GUI abstraction layer would also make it a lot easier to port plugins between various platforms (no need to write a new GUI for each of them).

    But of course nobody ever said the VST spec/SDK is sane in that regard (it was never designed to be cross-platform, I suppose).

    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.

    Using ELF is like using short-named global variables in your code with no prefix and no namespaces whatsoever. Retarded crap.
    You don't seem to understand the difference between binary formats and what (dynamic) linkers do with them.

    ELF ≠ libc

    ELF supports versioned symbols and such, but the default shared library loader does not use them, and by default most linkers don't create them. In any case, it's up to the application loading them to ask for it; I'm pretty sure neither Reaper nor the plugins do that. It's up to the library provider to support it. And I suppose the VST spec and/or SDK don't have provisions for this.

    There is also another issue: I'm not sure Gtk itself would like that, because of the way it implements its main loop etc., so sharing Gtk 2 & 3 in one application might fail even on Windows (but I didn't test that, so it's just a guess, and it might depend on what features you try to use, as Gtk is more than just a GUI library).

    Another solution might be to use out-of-process plugins, of course, but those might come with their own issues (especially on Windows?).

    Leave a comment:


  • brrrrttttt
    replied
    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.

    Leave a comment:


  • mattdm
    replied
    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

    Leave a comment:


  • Weasel
    replied
    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.
    Last edited by Weasel; 31 August 2018, 02:26 PM.

    Leave a comment:


  • mattdm
    replied
    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.

    Leave a comment:


  • tildearrow
    replied
    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...?

    Leave a comment:


  • Weasel
    replied
    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.

    Leave a comment:


  • Weasel
    replied
    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.

    Leave a comment:

Working...
X