“Don't break Debian” and bug fixes
.everyoneloves__top-leaderboard:empty,.everyoneloves__mid-leaderboard:empty,.everyoneloves__bot-mid-leaderboard:empty{ margin-bottom:0;
}
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
add a comment |
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
add a comment |
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
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
linux third-party
asked Jan 12 at 12:48
Arseni MourzenkoArseni Mourzenko
2,58351724
2,58351724
add a comment |
add a comment |
2 Answers
2
active
oldest
votes
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.
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
Jan 12 at 14:15
@ArseniMourzenko: There are actually both feature and security backports. Only the feature ones change the major version number.
– Robotic Extremeties
Jan 12 at 14:24
add a comment |
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.
An answer that doesn't discuss security backports is woefully incomplete in the context at hand.
– Charles Duffy
Jan 12 at 17:45
add a comment |
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
});
}
});
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
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
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.
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
Jan 12 at 14:15
@ArseniMourzenko: There are actually both feature and security backports. Only the feature ones change the major version number.
– Robotic Extremeties
Jan 12 at 14:24
add a comment |
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.
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
Jan 12 at 14:15
@ArseniMourzenko: There are actually both feature and security backports. Only the feature ones change the major version number.
– Robotic Extremeties
Jan 12 at 14:24
add a comment |
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.
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.
answered Jan 12 at 14:09
Robotic ExtremetiesRobotic Extremeties
13315
13315
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
Jan 12 at 14:15
@ArseniMourzenko: There are actually both feature and security backports. Only the feature ones change the major version number.
– Robotic Extremeties
Jan 12 at 14:24
add a comment |
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
Jan 12 at 14:15
@ArseniMourzenko: There are actually both feature and security backports. Only the feature ones change the major version number.
– Robotic Extremeties
Jan 12 at 14:24
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
Jan 12 at 14:15
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
Jan 12 at 14:15
@ArseniMourzenko: There are actually both feature and security backports. Only the feature ones change the major version number.
– Robotic Extremeties
Jan 12 at 14:24
@ArseniMourzenko: There are actually both feature and security backports. Only the feature ones change the major version number.
– Robotic Extremeties
Jan 12 at 14:24
add a comment |
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.
An answer that doesn't discuss security backports is woefully incomplete in the context at hand.
– Charles Duffy
Jan 12 at 17:45
add a comment |
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.
An answer that doesn't discuss security backports is woefully incomplete in the context at hand.
– Charles Duffy
Jan 12 at 17:45
add a comment |
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.
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.
answered Jan 12 at 13:39
Connor PeoplesConnor Peoples
1,175112
1,175112
An answer that doesn't discuss security backports is woefully incomplete in the context at hand.
– Charles Duffy
Jan 12 at 17:45
add a comment |
An answer that doesn't discuss security backports is woefully incomplete in the context at hand.
– Charles Duffy
Jan 12 at 17:45
An answer that doesn't discuss security backports is woefully incomplete in the context at hand.
– Charles Duffy
Jan 12 at 17:45
An answer that doesn't discuss security backports is woefully incomplete in the context at hand.
– Charles Duffy
Jan 12 at 17:45
add a comment |
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.
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
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
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
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