Announcement

Collapse
No announcement yet.

Fedora Looks To Lighten Its Default Curl Packages

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

  • #11
    Originally posted by BwackNinja View Post
    But when have you ever thought about sftp'ing a file using curl?
    Probably not from an interactive command-line, but as a library, that would be quite nice. libcurl is much more prevalent than libssh or libssh2; too bad openssh does not have a library - it would be sooo universal. Furthermore, rsync, my preferred mode of transfer, does not have a ready library either.

    Comment


    • #12
      Originally posted by BwackNinja View Post

      But when have you ever thought about sftp'ing a file using curl?
      if we split it out and compile it as systemd_curl_sftp_file_copy_tool.bin or systemd_curl_complete_batteries.bin will you let it live ?

      Comment


      • #13
        Originally posted by uxmkt View Post
        Probably not from an interactive command-line, but as a library, that would be quite nice. libcurl is much more prevalent than libssh or libssh2; too bad openssh does not have a library - it would be sooo universal. Furthermore, rsync, my preferred mode of transfer, does not have a ready library either.
        Right. In my day job, I have definitely - and less than 5 years ago - used libcurl as a single library for performing SFTP, HTTP and FTP transfers

        Comment


        • #14
          Libcurl has been the tool of choice for adding SSO with MS AD to php apps via its NTLM support, at least up to the point where MS went all ADFS. It is also used for making authenticated http calls to IIS servers.
          I imagine that there are quite a few of those setups still out there, so I would not be so quick in dropping NTLM support - albeit I also imagine that most php apps are running on more "server-focused" distributions than Fedora or, in any case, should be able to cope with having the "full" version of curl installed.

          Comment


          • #15
            I'd enable SFTP in libcurl-minimal now that "drop HTTPS because no enough people use it" is no longer an option for "people need an FTP-like but FTP's design is too archaic" but, otherwise, makes sense.

            To be honest, I'm surprised that it still takes so much googling to find a way to run a WebDAV server without going full Apache, given that every OS seems to build a client into its file manager now.

            Comment


            • #16
              Originally posted by WizardGed View Post
              This will be a pain, curl is like a Swiss army knife when dealing with networking/application issues especially in containers and curl is one of the few things I can expect in a container. I'm sure there are security benefits but for those that rely on containers from RedHat for base images that they do not modify, this will get annoyingly painful fast.
              When would you be using any of the non-default protocols in curl and not be in a position to build custom containers? In any case, and maybe I'm just too used to having easy access to self-hosting custom containers here, but making your own containers isn't exactly that hard. Within the company I work at, we barely have a single CI/CD process that can run on a standard container. Quite quickly, additional dependencies are needed

              Comment


              • #17
                Originally posted by AHSauge View Post

                When would you be using any of the non-default protocols in curl and not be in a position to build custom containers?
                Quite often in production. self built containers may be a thing in testing and development but in general using an unmodified base container image is recommended by Redhat as they can guarantee security of the base image and CVE tracking and remediation is incredibly simple. you also run into the inevitable issue of "who made what changes where?" and the inevitable pain involved in trying to maintain "The golden image" that you maintain and is really more like the spray painted gold garbage that has way too many customization and way too high an attack surface. Also on a more practical not it is significantly easier to answer the question of "how do we remediate and test our images for X Y or Z vulnerability if Redhat is already maintaining and patching new images for you and you just need to stay up to date.

                Originally posted by AHSauge View Post

                In any case, and maybe I'm just too used to having easy access to self-hosting custom containers here, but making your own containers isn't exactly that hard. Within the company I work at, we barely have a single CI/CD process that can run on a standard container. Quite quickly, additional dependencies are needed
                Like I said before it's not so much that it's hard, it's just that it's undesirable. it puts the accountability directly on your head for all vulnerabilities and application interactions vs the upstream container image vendor. usually most of the dependencies we require have maintained redhat images we can use and be sure are updated for the entire business.

                Little bit sidetracked on all this curl is just really useful to deal with all the business interactions in a wildfly application or supporting applications all within the pod your having an issue with.

                Comment


                • #18
                  Originally posted by WizardGed View Post

                  Quite often in production. self built containers may be a thing in testing and development but in general using an unmodified base container image is recommended by Redhat as they can guarantee security of the base image and CVE tracking and remediation is incredibly simple. you also run into the inevitable issue of "who made what changes where?" and the inevitable pain involved in trying to maintain "The golden image" that you maintain and is really more like the spray painted gold garbage that has way too many customization and way too high an attack surface. Also on a more practical not it is significantly easier to answer the question of "how do we remediate and test our images for X Y or Z vulnerability if Redhat is already maintaining and patching new images for you and you just need to stay up to date.



                  Like I said before it's not so much that it's hard, it's just that it's undesirable. it puts the accountability directly on your head for all vulnerabilities and application interactions vs the upstream container image vendor. usually most of the dependencies we require have maintained redhat images we can use and be sure are updated for the entire business.

                  Little bit sidetracked on all this curl is just really useful to deal with all the business interactions in a wildfly application or supporting applications all within the pod your having an issue with.
                  What are you talking about?

                  All you need to get the old behavior is

                  FROM fedora:whatever

                  RUN dnf install curl-full

                  That's it! There is absolutely nothing "undesirable" about this. I'm not sure how installing another package provided by the os makes you responsible for os wide security vulnerabilities, it's not like you are building the image from scratch

                  Comment


                  • #19
                    Originally posted by partcyborg View Post

                    What are you talking about?

                    All you need to get the old behavior is

                    FROM fedora:whatever

                    RUN dnf install curl-full

                    That's it! There is absolutely nothing "undesirable" about this. I'm not sure how installing another package provided by the os makes you responsible for os wide security vulnerabilities, it's not like you are building the image from scratch
                    If you have to deal with banking or really any high level compliance it isn't that simple. that needs to be stored in git, tracked and scanned and ensured that there will be no possibility for poor configurations or easy elevation of privilege. for curl this is most likely not a major issue however you cannot simply dnf install all the packages you'd find in a redhat JBoss eap image and get that image. they provide configurations, mitigations and in general have thought of most of the considerations you will not have when building the image. it's why they do not encourage rebuilding there base images. and yes installing additional packages redhat has not distributed with the image does make you responsible for any interactions or issues that customization may make. ask your compliance officer wherever you work. like I said most likely not a big consideration for curl however an auditor isn't going to distinguish between curl or a web server.

                    Comment


                    • #20
                      Originally posted by WizardGed View Post

                      If you have to deal with banking or really any high level compliance it isn't that simple.
                      I may be misunderstanding something, but I never really hear "Fedora" and "banking" in a single sentence in this context. As the solution for containerization, Redhat provides UBI images which are RHEL-based, don't they? Do you expect the curl-minimal change to trickle into UBI in some time, causing trouble?

                      Comment

                      Working...
                      X