“Don't break Debian” and bug fixes












2















Don't break Debian page is quite clear that always installing the latest versions of third-party software from from places other than official Debian repositories is not a good idea. Although the article tells a lot of things, it comes in essence to the following points:




  • Third-party sites may not be trusted as much as Debian repositories.

  • Newer versions of a software product may contain new bugs.

  • Newer versions haven't been tested thoroughly with a specific version of Debian.

  • There may be issues between newer versions of a software and other software products installed on Debian machine.


I'm not sure how should I apply the advice in the following situation. I'm deploying a cluster of virtual machine which will be used to host several instances of RabbitMQ. The official Debian repositories for Debian Stretch come with version 3.6.6, which, it appears, was released more than two years ago, with a lot of versions being released since then.



My use of RabbitMQ is very basic, which means that I won't probably benefit from all the new features which were released. What scares me, however, is that most of the new releases claim to have fixed bugs, which, I suppose, includes security issues.



Therefore, should I ignore the recommendation of Debian documentation and install the software product such as RabbitMQ from the source recommended in the documentation of RabbitMQ, or should I stick with the old version provided through official Debian repositories?



Or there is absolutely no way to answer this question, without checking the entire list of changes and manually evaluating the risks?



Note: although I illustrated my question with RabbitMQ, it applies to most server-side software I have to install, such as PostgreSQL.










share|improve this question



























    2















    Don't break Debian page is quite clear that always installing the latest versions of third-party software from from places other than official Debian repositories is not a good idea. Although the article tells a lot of things, it comes in essence to the following points:




    • Third-party sites may not be trusted as much as Debian repositories.

    • Newer versions of a software product may contain new bugs.

    • Newer versions haven't been tested thoroughly with a specific version of Debian.

    • There may be issues between newer versions of a software and other software products installed on Debian machine.


    I'm not sure how should I apply the advice in the following situation. I'm deploying a cluster of virtual machine which will be used to host several instances of RabbitMQ. The official Debian repositories for Debian Stretch come with version 3.6.6, which, it appears, was released more than two years ago, with a lot of versions being released since then.



    My use of RabbitMQ is very basic, which means that I won't probably benefit from all the new features which were released. What scares me, however, is that most of the new releases claim to have fixed bugs, which, I suppose, includes security issues.



    Therefore, should I ignore the recommendation of Debian documentation and install the software product such as RabbitMQ from the source recommended in the documentation of RabbitMQ, or should I stick with the old version provided through official Debian repositories?



    Or there is absolutely no way to answer this question, without checking the entire list of changes and manually evaluating the risks?



    Note: although I illustrated my question with RabbitMQ, it applies to most server-side software I have to install, such as PostgreSQL.










    share|improve this question

























      2












      2








      2








      Don't break Debian page is quite clear that always installing the latest versions of third-party software from from places other than official Debian repositories is not a good idea. Although the article tells a lot of things, it comes in essence to the following points:




      • Third-party sites may not be trusted as much as Debian repositories.

      • Newer versions of a software product may contain new bugs.

      • Newer versions haven't been tested thoroughly with a specific version of Debian.

      • There may be issues between newer versions of a software and other software products installed on Debian machine.


      I'm not sure how should I apply the advice in the following situation. I'm deploying a cluster of virtual machine which will be used to host several instances of RabbitMQ. The official Debian repositories for Debian Stretch come with version 3.6.6, which, it appears, was released more than two years ago, with a lot of versions being released since then.



      My use of RabbitMQ is very basic, which means that I won't probably benefit from all the new features which were released. What scares me, however, is that most of the new releases claim to have fixed bugs, which, I suppose, includes security issues.



      Therefore, should I ignore the recommendation of Debian documentation and install the software product such as RabbitMQ from the source recommended in the documentation of RabbitMQ, or should I stick with the old version provided through official Debian repositories?



      Or there is absolutely no way to answer this question, without checking the entire list of changes and manually evaluating the risks?



      Note: although I illustrated my question with RabbitMQ, it applies to most server-side software I have to install, such as PostgreSQL.










      share|improve this question














      Don't break Debian page is quite clear that always installing the latest versions of third-party software from from places other than official Debian repositories is not a good idea. Although the article tells a lot of things, it comes in essence to the following points:




      • Third-party sites may not be trusted as much as Debian repositories.

      • Newer versions of a software product may contain new bugs.

      • Newer versions haven't been tested thoroughly with a specific version of Debian.

      • There may be issues between newer versions of a software and other software products installed on Debian machine.


      I'm not sure how should I apply the advice in the following situation. I'm deploying a cluster of virtual machine which will be used to host several instances of RabbitMQ. The official Debian repositories for Debian Stretch come with version 3.6.6, which, it appears, was released more than two years ago, with a lot of versions being released since then.



      My use of RabbitMQ is very basic, which means that I won't probably benefit from all the new features which were released. What scares me, however, is that most of the new releases claim to have fixed bugs, which, I suppose, includes security issues.



      Therefore, should I ignore the recommendation of Debian documentation and install the software product such as RabbitMQ from the source recommended in the documentation of RabbitMQ, or should I stick with the old version provided through official Debian repositories?



      Or there is absolutely no way to answer this question, without checking the entire list of changes and manually evaluating the risks?



      Note: although I illustrated my question with RabbitMQ, it applies to most server-side software I have to install, such as PostgreSQL.







      linux third-party






      share|improve this question













      share|improve this question











      share|improve this question




      share|improve this question










      asked 2 days ago









      Arseni MourzenkoArseni Mourzenko

      2,54351624




      2,54351624






















          2 Answers
          2






          active

          oldest

          votes


















          4














          What you might not have thought of or read about is that Debian backports security fixes from newer versions of software to current versions. For instance, one of the Spectre-associated CVEs on Debian's security tracker shows all supported Debian versions, including oldstable. Although these really old Debian versions won’t be receiving brand-new kernels, they will be getting security fixes backported to the stable kernels.



          In the case of RabbitMQ, you can see from the package tracker that security fixes have been made for the old versions in Debian Stable.



          Additionally, if you do need a newer version of this program than the one in Stable, you can install it from the “stable-bpo” branch or follow the directions in this Server Fault question to get it from Testing or Unstable. This is usually the safer alternative to installing the package from the project website directly.






          share|improve this answer
























          • Interesting. I've read about the backports in the article I linked in the beginning of my question, but I misunderstood that a backport won't change the version number of a package. Now that I think about it, it makes perfect sense to keep the old version number.

            – Arseni Mourzenko
            2 days ago











          • @ArseniMourzenko: There are actually both feature and security backports. Only the feature ones change the major version number.

            – Robotic Extremeties
            2 days ago





















          -1














          Debian as an OS has made stability their major focus rather than security. It's not that they don't try to make certain efforts to reduce security issues, but they do fall behind the wagon on major application versions. If you are looking for a more up to date system, then I highly recommend going with Ubuntu which is Debian based, but tends to keep with current trends a lot better. Many of the tools you are familiar with from Debian transfer over well.



          If you must remain with Debian, then you have to acknowledge you are exposing potentially unstable elements to Debian due to lack of testing. You may run into other dependency issues where Debian has released older versions of software than you need. You could end up managing a lot of the dependencies yourself which further means managing security patches, etc. It can be done, but it may be a lot more work than working with an OS that supports your needed patch levels natively.



          Over all, I think this is a case of getting the right tool for the job. If the older software versions meet your technical needs, then enjoy them for now and upgrade when/if you need the newer features. If you don't like the idea of being limited from what's possible, something I hate, then you may need to opt for a more updated OS.






          share|improve this answer








          New contributor




          Connor Peoples is a new contributor to this site. Take care in asking for clarification, commenting, and answering.
          Check out our Code of Conduct.





















          • An answer that doesn't discuss security backports is woefully incomplete in the context at hand.

            – Charles Duffy
            2 days ago











          Your Answer








          StackExchange.ready(function() {
          var channelOptions = {
          tags: "".split(" "),
          id: "162"
          };
          initTagRenderer("".split(" "), "".split(" "), channelOptions);

          StackExchange.using("externalEditor", function() {
          // Have to fire editor after snippets, if snippets enabled
          if (StackExchange.settings.snippets.snippetsEnabled) {
          StackExchange.using("snippets", function() {
          createEditor();
          });
          }
          else {
          createEditor();
          }
          });

          function createEditor() {
          StackExchange.prepareEditor({
          heartbeatType: 'answer',
          autoActivateHeartbeat: false,
          convertImagesToLinks: false,
          noModals: true,
          showLowRepImageUploadWarning: true,
          reputationToPostImages: null,
          bindNavPrevention: true,
          postfix: "",
          imageUploader: {
          brandingHtml: "Powered by u003ca class="icon-imgur-white" href="https://imgur.com/"u003eu003c/au003e",
          contentPolicyHtml: "User contributions licensed under u003ca href="https://creativecommons.org/licenses/by-sa/3.0/"u003ecc by-sa 3.0 with attribution requiredu003c/au003e u003ca href="https://stackoverflow.com/legal/content-policy"u003e(content policy)u003c/au003e",
          allowUrls: true
          },
          noCode: true, onDemand: true,
          discardSelector: ".discard-answer"
          ,immediatelyShowMarkdownHelp:true
          });


          }
          });














          draft saved

          draft discarded


















          StackExchange.ready(
          function () {
          StackExchange.openid.initPostLogin('.new-post-login', 'https%3a%2f%2fsecurity.stackexchange.com%2fquestions%2f201335%2fdont-break-debian-and-bug-fixes%23new-answer', 'question_page');
          }
          );

          Post as a guest















          Required, but never shown

























          2 Answers
          2






          active

          oldest

          votes








          2 Answers
          2






          active

          oldest

          votes









          active

          oldest

          votes






          active

          oldest

          votes









          4














          What you might not have thought of or read about is that Debian backports security fixes from newer versions of software to current versions. For instance, one of the Spectre-associated CVEs on Debian's security tracker shows all supported Debian versions, including oldstable. Although these really old Debian versions won’t be receiving brand-new kernels, they will be getting security fixes backported to the stable kernels.



          In the case of RabbitMQ, you can see from the package tracker that security fixes have been made for the old versions in Debian Stable.



          Additionally, if you do need a newer version of this program than the one in Stable, you can install it from the “stable-bpo” branch or follow the directions in this Server Fault question to get it from Testing or Unstable. This is usually the safer alternative to installing the package from the project website directly.






          share|improve this answer
























          • Interesting. I've read about the backports in the article I linked in the beginning of my question, but I misunderstood that a backport won't change the version number of a package. Now that I think about it, it makes perfect sense to keep the old version number.

            – Arseni Mourzenko
            2 days ago











          • @ArseniMourzenko: There are actually both feature and security backports. Only the feature ones change the major version number.

            – Robotic Extremeties
            2 days ago


















          4














          What you might not have thought of or read about is that Debian backports security fixes from newer versions of software to current versions. For instance, one of the Spectre-associated CVEs on Debian's security tracker shows all supported Debian versions, including oldstable. Although these really old Debian versions won’t be receiving brand-new kernels, they will be getting security fixes backported to the stable kernels.



          In the case of RabbitMQ, you can see from the package tracker that security fixes have been made for the old versions in Debian Stable.



          Additionally, if you do need a newer version of this program than the one in Stable, you can install it from the “stable-bpo” branch or follow the directions in this Server Fault question to get it from Testing or Unstable. This is usually the safer alternative to installing the package from the project website directly.






          share|improve this answer
























          • Interesting. I've read about the backports in the article I linked in the beginning of my question, but I misunderstood that a backport won't change the version number of a package. Now that I think about it, it makes perfect sense to keep the old version number.

            – Arseni Mourzenko
            2 days ago











          • @ArseniMourzenko: There are actually both feature and security backports. Only the feature ones change the major version number.

            – Robotic Extremeties
            2 days ago
















          4












          4








          4







          What you might not have thought of or read about is that Debian backports security fixes from newer versions of software to current versions. For instance, one of the Spectre-associated CVEs on Debian's security tracker shows all supported Debian versions, including oldstable. Although these really old Debian versions won’t be receiving brand-new kernels, they will be getting security fixes backported to the stable kernels.



          In the case of RabbitMQ, you can see from the package tracker that security fixes have been made for the old versions in Debian Stable.



          Additionally, if you do need a newer version of this program than the one in Stable, you can install it from the “stable-bpo” branch or follow the directions in this Server Fault question to get it from Testing or Unstable. This is usually the safer alternative to installing the package from the project website directly.






          share|improve this answer













          What you might not have thought of or read about is that Debian backports security fixes from newer versions of software to current versions. For instance, one of the Spectre-associated CVEs on Debian's security tracker shows all supported Debian versions, including oldstable. Although these really old Debian versions won’t be receiving brand-new kernels, they will be getting security fixes backported to the stable kernels.



          In the case of RabbitMQ, you can see from the package tracker that security fixes have been made for the old versions in Debian Stable.



          Additionally, if you do need a newer version of this program than the one in Stable, you can install it from the “stable-bpo” branch or follow the directions in this Server Fault question to get it from Testing or Unstable. This is usually the safer alternative to installing the package from the project website directly.







          share|improve this answer












          share|improve this answer



          share|improve this answer










          answered 2 days ago









          Robotic ExtremetiesRobotic Extremeties

          1164




          1164













          • Interesting. I've read about the backports in the article I linked in the beginning of my question, but I misunderstood that a backport won't change the version number of a package. Now that I think about it, it makes perfect sense to keep the old version number.

            – Arseni Mourzenko
            2 days ago











          • @ArseniMourzenko: There are actually both feature and security backports. Only the feature ones change the major version number.

            – Robotic Extremeties
            2 days ago





















          • Interesting. I've read about the backports in the article I linked in the beginning of my question, but I misunderstood that a backport won't change the version number of a package. Now that I think about it, it makes perfect sense to keep the old version number.

            – Arseni Mourzenko
            2 days ago











          • @ArseniMourzenko: There are actually both feature and security backports. Only the feature ones change the major version number.

            – Robotic Extremeties
            2 days ago



















          Interesting. I've read about the backports in the article I linked in the beginning of my question, but I misunderstood that a backport won't change the version number of a package. Now that I think about it, it makes perfect sense to keep the old version number.

          – Arseni Mourzenko
          2 days ago





          Interesting. I've read about the backports in the article I linked in the beginning of my question, but I misunderstood that a backport won't change the version number of a package. Now that I think about it, it makes perfect sense to keep the old version number.

          – Arseni Mourzenko
          2 days ago













          @ArseniMourzenko: There are actually both feature and security backports. Only the feature ones change the major version number.

          – Robotic Extremeties
          2 days ago







          @ArseniMourzenko: There are actually both feature and security backports. Only the feature ones change the major version number.

          – Robotic Extremeties
          2 days ago















          -1














          Debian as an OS has made stability their major focus rather than security. It's not that they don't try to make certain efforts to reduce security issues, but they do fall behind the wagon on major application versions. If you are looking for a more up to date system, then I highly recommend going with Ubuntu which is Debian based, but tends to keep with current trends a lot better. Many of the tools you are familiar with from Debian transfer over well.



          If you must remain with Debian, then you have to acknowledge you are exposing potentially unstable elements to Debian due to lack of testing. You may run into other dependency issues where Debian has released older versions of software than you need. You could end up managing a lot of the dependencies yourself which further means managing security patches, etc. It can be done, but it may be a lot more work than working with an OS that supports your needed patch levels natively.



          Over all, I think this is a case of getting the right tool for the job. If the older software versions meet your technical needs, then enjoy them for now and upgrade when/if you need the newer features. If you don't like the idea of being limited from what's possible, something I hate, then you may need to opt for a more updated OS.






          share|improve this answer








          New contributor




          Connor Peoples is a new contributor to this site. Take care in asking for clarification, commenting, and answering.
          Check out our Code of Conduct.





















          • An answer that doesn't discuss security backports is woefully incomplete in the context at hand.

            – Charles Duffy
            2 days ago
















          -1














          Debian as an OS has made stability their major focus rather than security. It's not that they don't try to make certain efforts to reduce security issues, but they do fall behind the wagon on major application versions. If you are looking for a more up to date system, then I highly recommend going with Ubuntu which is Debian based, but tends to keep with current trends a lot better. Many of the tools you are familiar with from Debian transfer over well.



          If you must remain with Debian, then you have to acknowledge you are exposing potentially unstable elements to Debian due to lack of testing. You may run into other dependency issues where Debian has released older versions of software than you need. You could end up managing a lot of the dependencies yourself which further means managing security patches, etc. It can be done, but it may be a lot more work than working with an OS that supports your needed patch levels natively.



          Over all, I think this is a case of getting the right tool for the job. If the older software versions meet your technical needs, then enjoy them for now and upgrade when/if you need the newer features. If you don't like the idea of being limited from what's possible, something I hate, then you may need to opt for a more updated OS.






          share|improve this answer








          New contributor




          Connor Peoples is a new contributor to this site. Take care in asking for clarification, commenting, and answering.
          Check out our Code of Conduct.





















          • An answer that doesn't discuss security backports is woefully incomplete in the context at hand.

            – Charles Duffy
            2 days ago














          -1












          -1








          -1







          Debian as an OS has made stability their major focus rather than security. It's not that they don't try to make certain efforts to reduce security issues, but they do fall behind the wagon on major application versions. If you are looking for a more up to date system, then I highly recommend going with Ubuntu which is Debian based, but tends to keep with current trends a lot better. Many of the tools you are familiar with from Debian transfer over well.



          If you must remain with Debian, then you have to acknowledge you are exposing potentially unstable elements to Debian due to lack of testing. You may run into other dependency issues where Debian has released older versions of software than you need. You could end up managing a lot of the dependencies yourself which further means managing security patches, etc. It can be done, but it may be a lot more work than working with an OS that supports your needed patch levels natively.



          Over all, I think this is a case of getting the right tool for the job. If the older software versions meet your technical needs, then enjoy them for now and upgrade when/if you need the newer features. If you don't like the idea of being limited from what's possible, something I hate, then you may need to opt for a more updated OS.






          share|improve this answer








          New contributor




          Connor Peoples is a new contributor to this site. Take care in asking for clarification, commenting, and answering.
          Check out our Code of Conduct.










          Debian as an OS has made stability their major focus rather than security. It's not that they don't try to make certain efforts to reduce security issues, but they do fall behind the wagon on major application versions. If you are looking for a more up to date system, then I highly recommend going with Ubuntu which is Debian based, but tends to keep with current trends a lot better. Many of the tools you are familiar with from Debian transfer over well.



          If you must remain with Debian, then you have to acknowledge you are exposing potentially unstable elements to Debian due to lack of testing. You may run into other dependency issues where Debian has released older versions of software than you need. You could end up managing a lot of the dependencies yourself which further means managing security patches, etc. It can be done, but it may be a lot more work than working with an OS that supports your needed patch levels natively.



          Over all, I think this is a case of getting the right tool for the job. If the older software versions meet your technical needs, then enjoy them for now and upgrade when/if you need the newer features. If you don't like the idea of being limited from what's possible, something I hate, then you may need to opt for a more updated OS.







          share|improve this answer








          New contributor




          Connor Peoples is a new contributor to this site. Take care in asking for clarification, commenting, and answering.
          Check out our Code of Conduct.









          share|improve this answer



          share|improve this answer






          New contributor




          Connor Peoples is a new contributor to this site. Take care in asking for clarification, commenting, and answering.
          Check out our Code of Conduct.









          answered 2 days ago









          Connor PeoplesConnor Peoples

          1,047112




          1,047112




          New contributor




          Connor Peoples is a new contributor to this site. Take care in asking for clarification, commenting, and answering.
          Check out our Code of Conduct.





          New contributor





          Connor Peoples is a new contributor to this site. Take care in asking for clarification, commenting, and answering.
          Check out our Code of Conduct.






          Connor Peoples is a new contributor to this site. Take care in asking for clarification, commenting, and answering.
          Check out our Code of Conduct.













          • An answer that doesn't discuss security backports is woefully incomplete in the context at hand.

            – Charles Duffy
            2 days ago



















          • An answer that doesn't discuss security backports is woefully incomplete in the context at hand.

            – Charles Duffy
            2 days ago

















          An answer that doesn't discuss security backports is woefully incomplete in the context at hand.

          – Charles Duffy
          2 days ago





          An answer that doesn't discuss security backports is woefully incomplete in the context at hand.

          – Charles Duffy
          2 days ago


















          draft saved

          draft discarded




















































          Thanks for contributing an answer to Information Security Stack Exchange!


          • Please be sure to answer the question. Provide details and share your research!

          But avoid



          • Asking for help, clarification, or responding to other answers.

          • Making statements based on opinion; back them up with references or personal experience.


          To learn more, see our tips on writing great answers.




          draft saved


          draft discarded














          StackExchange.ready(
          function () {
          StackExchange.openid.initPostLogin('.new-post-login', 'https%3a%2f%2fsecurity.stackexchange.com%2fquestions%2f201335%2fdont-break-debian-and-bug-fixes%23new-answer', 'question_page');
          }
          );

          Post as a guest















          Required, but never shown





















































          Required, but never shown














          Required, but never shown












          Required, but never shown







          Required, but never shown

































          Required, but never shown














          Required, but never shown












          Required, but never shown







          Required, but never shown







          Popular posts from this blog

          "Incorrect syntax near the keyword 'ON'. (on update cascade, on delete cascade,)

          Alcedinidae

          RAC Tourist Trophy