Why isn't it a security risk to add to sources.list?

The name of the pictureThe name of the pictureThe name of the pictureClash Royale CLAN TAG#URR8PPP





.everyoneloves__top-leaderboard:empty,.everyoneloves__mid-leaderboard:empty margin-bottom:0;







up vote
3
down vote

favorite












To install Sublime, it wants me to add a GPG key and a sources.list entry so that apt-get can find it. A couple of other programs have asked for the same. Why isn't it a security risk to add more domains to sources.list?



That is: suppose package A is supposed to come from host B. I add host C in a new sources.list. Host C gets subverted, an attacker hosts a malicious package and calls it A. Next time I try to update A, apt-get checks the sources and decides to download it from C instead of B, and I get the malicious version.







share|improve this question

















  • 5




    Who claimed that it wasn't?
    – Charles Duffy
    2 days ago
















up vote
3
down vote

favorite












To install Sublime, it wants me to add a GPG key and a sources.list entry so that apt-get can find it. A couple of other programs have asked for the same. Why isn't it a security risk to add more domains to sources.list?



That is: suppose package A is supposed to come from host B. I add host C in a new sources.list. Host C gets subverted, an attacker hosts a malicious package and calls it A. Next time I try to update A, apt-get checks the sources and decides to download it from C instead of B, and I get the malicious version.







share|improve this question

















  • 5




    Who claimed that it wasn't?
    – Charles Duffy
    2 days ago












up vote
3
down vote

favorite









up vote
3
down vote

favorite











To install Sublime, it wants me to add a GPG key and a sources.list entry so that apt-get can find it. A couple of other programs have asked for the same. Why isn't it a security risk to add more domains to sources.list?



That is: suppose package A is supposed to come from host B. I add host C in a new sources.list. Host C gets subverted, an attacker hosts a malicious package and calls it A. Next time I try to update A, apt-get checks the sources and decides to download it from C instead of B, and I get the malicious version.







share|improve this question













To install Sublime, it wants me to add a GPG key and a sources.list entry so that apt-get can find it. A couple of other programs have asked for the same. Why isn't it a security risk to add more domains to sources.list?



That is: suppose package A is supposed to come from host B. I add host C in a new sources.list. Host C gets subverted, an attacker hosts a malicious package and calls it A. Next time I try to update A, apt-get checks the sources and decides to download it from C instead of B, and I get the malicious version.









share|improve this question












share|improve this question




share|improve this question








edited yesterday









jwodder

17518




17518









asked 2 days ago









Sam Jaques

1263




1263







  • 5




    Who claimed that it wasn't?
    – Charles Duffy
    2 days ago












  • 5




    Who claimed that it wasn't?
    – Charles Duffy
    2 days ago







5




5




Who claimed that it wasn't?
– Charles Duffy
2 days ago




Who claimed that it wasn't?
– Charles Duffy
2 days ago










1 Answer
1






active

oldest

votes

















up vote
13
down vote



accepted










The answer: It is.



It's always a risk in introducing additional sources for packages, irregardless of what distro/OS you're using. The use of GPG keys, in theory, helps to mitigate the risks, since in theory, someone would have to:



  1. get access to the server where the binaries are being served from

  2. get access to the private GPG key that was used to sign the binaries

  3. package new versions of compromised binaries, sign them, and then put on server

In this scenario, someone would have to get through multiple layers to do something nefarious. As is always the case with security. It's all about layers! In order for a community to thrive and stand on the shoulders of others, you have to be willing to forgo isolation, and put your trust in others.



And keep in mind, the servers that serve files have been compromised before to varying degrees, but it's typically caught right away and can be addressed in short order.



Previous Attacks



  • Fedora Web Site Hacked, But the Servers Undamaged !

  • Malicious Software Packages Found On Arch Linux User Repository

  • Malware Found in Arch Linux AUR Package Repository

Tips



  • Always scrutinize URLs and make sure they are legit

  • Don't add repos unless you absolutely need a package from them

  • Periodically vet your sources.list

  • Periodically vet the GPG keys used by sites to sign packages

  • Be diligent about staying up to date on packages





share|improve this answer



















  • 2




    Along with periodically vetting sources.list (and sources.list.d/*, I’d recommend periodically vetting the installed keys.
    – Stephen Kitt
    2 days ago










  • @StephenKitt - excellent point, I'll add it.
    – slm♦
    2 days ago










  • Also, make use of the Signed-By attribute to place restrictions upon keys rather than adding them globally.
    – JdeBP
    2 days ago










  • By "vet your sources.list", you mean to look through it and remove anything I don't need anymore?
    – Sam Jaques
    2 days ago






  • 1




    @SamJaques yeah eliminate anything you no longer need but more importantly make sure the URLs remain legit.
    – slm♦
    2 days ago










Your Answer







StackExchange.ready(function()
var channelOptions =
tags: "".split(" "),
id: "106"
;
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',
convertImagesToLinks: false,
noModals: false,
showLowRepImageUploadWarning: true,
reputationToPostImages: null,
bindNavPrevention: true,
postfix: "",
onDemand: true,
discardSelector: ".discard-answer"
,immediatelyShowMarkdownHelp:true
);



);








 

draft saved


draft discarded


















StackExchange.ready(
function ()
StackExchange.openid.initPostLogin('.new-post-login', 'https%3a%2f%2funix.stackexchange.com%2fquestions%2f460525%2fwhy-isnt-it-a-security-risk-to-add-to-sources-list%23new-answer', 'question_page');

);

Post as a guest






























1 Answer
1






active

oldest

votes








1 Answer
1






active

oldest

votes









active

oldest

votes






active

oldest

votes








up vote
13
down vote



accepted










The answer: It is.



It's always a risk in introducing additional sources for packages, irregardless of what distro/OS you're using. The use of GPG keys, in theory, helps to mitigate the risks, since in theory, someone would have to:



  1. get access to the server where the binaries are being served from

  2. get access to the private GPG key that was used to sign the binaries

  3. package new versions of compromised binaries, sign them, and then put on server

In this scenario, someone would have to get through multiple layers to do something nefarious. As is always the case with security. It's all about layers! In order for a community to thrive and stand on the shoulders of others, you have to be willing to forgo isolation, and put your trust in others.



And keep in mind, the servers that serve files have been compromised before to varying degrees, but it's typically caught right away and can be addressed in short order.



Previous Attacks



  • Fedora Web Site Hacked, But the Servers Undamaged !

  • Malicious Software Packages Found On Arch Linux User Repository

  • Malware Found in Arch Linux AUR Package Repository

Tips



  • Always scrutinize URLs and make sure they are legit

  • Don't add repos unless you absolutely need a package from them

  • Periodically vet your sources.list

  • Periodically vet the GPG keys used by sites to sign packages

  • Be diligent about staying up to date on packages





share|improve this answer



















  • 2




    Along with periodically vetting sources.list (and sources.list.d/*, I’d recommend periodically vetting the installed keys.
    – Stephen Kitt
    2 days ago










  • @StephenKitt - excellent point, I'll add it.
    – slm♦
    2 days ago










  • Also, make use of the Signed-By attribute to place restrictions upon keys rather than adding them globally.
    – JdeBP
    2 days ago










  • By "vet your sources.list", you mean to look through it and remove anything I don't need anymore?
    – Sam Jaques
    2 days ago






  • 1




    @SamJaques yeah eliminate anything you no longer need but more importantly make sure the URLs remain legit.
    – slm♦
    2 days ago














up vote
13
down vote



accepted










The answer: It is.



It's always a risk in introducing additional sources for packages, irregardless of what distro/OS you're using. The use of GPG keys, in theory, helps to mitigate the risks, since in theory, someone would have to:



  1. get access to the server where the binaries are being served from

  2. get access to the private GPG key that was used to sign the binaries

  3. package new versions of compromised binaries, sign them, and then put on server

In this scenario, someone would have to get through multiple layers to do something nefarious. As is always the case with security. It's all about layers! In order for a community to thrive and stand on the shoulders of others, you have to be willing to forgo isolation, and put your trust in others.



And keep in mind, the servers that serve files have been compromised before to varying degrees, but it's typically caught right away and can be addressed in short order.



Previous Attacks



  • Fedora Web Site Hacked, But the Servers Undamaged !

  • Malicious Software Packages Found On Arch Linux User Repository

  • Malware Found in Arch Linux AUR Package Repository

Tips



  • Always scrutinize URLs and make sure they are legit

  • Don't add repos unless you absolutely need a package from them

  • Periodically vet your sources.list

  • Periodically vet the GPG keys used by sites to sign packages

  • Be diligent about staying up to date on packages





share|improve this answer



















  • 2




    Along with periodically vetting sources.list (and sources.list.d/*, I’d recommend periodically vetting the installed keys.
    – Stephen Kitt
    2 days ago










  • @StephenKitt - excellent point, I'll add it.
    – slm♦
    2 days ago










  • Also, make use of the Signed-By attribute to place restrictions upon keys rather than adding them globally.
    – JdeBP
    2 days ago










  • By "vet your sources.list", you mean to look through it and remove anything I don't need anymore?
    – Sam Jaques
    2 days ago






  • 1




    @SamJaques yeah eliminate anything you no longer need but more importantly make sure the URLs remain legit.
    – slm♦
    2 days ago












up vote
13
down vote



accepted







up vote
13
down vote



accepted






The answer: It is.



It's always a risk in introducing additional sources for packages, irregardless of what distro/OS you're using. The use of GPG keys, in theory, helps to mitigate the risks, since in theory, someone would have to:



  1. get access to the server where the binaries are being served from

  2. get access to the private GPG key that was used to sign the binaries

  3. package new versions of compromised binaries, sign them, and then put on server

In this scenario, someone would have to get through multiple layers to do something nefarious. As is always the case with security. It's all about layers! In order for a community to thrive and stand on the shoulders of others, you have to be willing to forgo isolation, and put your trust in others.



And keep in mind, the servers that serve files have been compromised before to varying degrees, but it's typically caught right away and can be addressed in short order.



Previous Attacks



  • Fedora Web Site Hacked, But the Servers Undamaged !

  • Malicious Software Packages Found On Arch Linux User Repository

  • Malware Found in Arch Linux AUR Package Repository

Tips



  • Always scrutinize URLs and make sure they are legit

  • Don't add repos unless you absolutely need a package from them

  • Periodically vet your sources.list

  • Periodically vet the GPG keys used by sites to sign packages

  • Be diligent about staying up to date on packages





share|improve this answer















The answer: It is.



It's always a risk in introducing additional sources for packages, irregardless of what distro/OS you're using. The use of GPG keys, in theory, helps to mitigate the risks, since in theory, someone would have to:



  1. get access to the server where the binaries are being served from

  2. get access to the private GPG key that was used to sign the binaries

  3. package new versions of compromised binaries, sign them, and then put on server

In this scenario, someone would have to get through multiple layers to do something nefarious. As is always the case with security. It's all about layers! In order for a community to thrive and stand on the shoulders of others, you have to be willing to forgo isolation, and put your trust in others.



And keep in mind, the servers that serve files have been compromised before to varying degrees, but it's typically caught right away and can be addressed in short order.



Previous Attacks



  • Fedora Web Site Hacked, But the Servers Undamaged !

  • Malicious Software Packages Found On Arch Linux User Repository

  • Malware Found in Arch Linux AUR Package Repository

Tips



  • Always scrutinize URLs and make sure they are legit

  • Don't add repos unless you absolutely need a package from them

  • Periodically vet your sources.list

  • Periodically vet the GPG keys used by sites to sign packages

  • Be diligent about staying up to date on packages






share|improve this answer















share|improve this answer



share|improve this answer








edited 2 days ago


























answered 2 days ago









slm♦

232k65479648




232k65479648







  • 2




    Along with periodically vetting sources.list (and sources.list.d/*, I’d recommend periodically vetting the installed keys.
    – Stephen Kitt
    2 days ago










  • @StephenKitt - excellent point, I'll add it.
    – slm♦
    2 days ago










  • Also, make use of the Signed-By attribute to place restrictions upon keys rather than adding them globally.
    – JdeBP
    2 days ago










  • By "vet your sources.list", you mean to look through it and remove anything I don't need anymore?
    – Sam Jaques
    2 days ago






  • 1




    @SamJaques yeah eliminate anything you no longer need but more importantly make sure the URLs remain legit.
    – slm♦
    2 days ago












  • 2




    Along with periodically vetting sources.list (and sources.list.d/*, I’d recommend periodically vetting the installed keys.
    – Stephen Kitt
    2 days ago










  • @StephenKitt - excellent point, I'll add it.
    – slm♦
    2 days ago










  • Also, make use of the Signed-By attribute to place restrictions upon keys rather than adding them globally.
    – JdeBP
    2 days ago










  • By "vet your sources.list", you mean to look through it and remove anything I don't need anymore?
    – Sam Jaques
    2 days ago






  • 1




    @SamJaques yeah eliminate anything you no longer need but more importantly make sure the URLs remain legit.
    – slm♦
    2 days ago







2




2




Along with periodically vetting sources.list (and sources.list.d/*, I’d recommend periodically vetting the installed keys.
– Stephen Kitt
2 days ago




Along with periodically vetting sources.list (and sources.list.d/*, I’d recommend periodically vetting the installed keys.
– Stephen Kitt
2 days ago












@StephenKitt - excellent point, I'll add it.
– slm♦
2 days ago




@StephenKitt - excellent point, I'll add it.
– slm♦
2 days ago












Also, make use of the Signed-By attribute to place restrictions upon keys rather than adding them globally.
– JdeBP
2 days ago




Also, make use of the Signed-By attribute to place restrictions upon keys rather than adding them globally.
– JdeBP
2 days ago












By "vet your sources.list", you mean to look through it and remove anything I don't need anymore?
– Sam Jaques
2 days ago




By "vet your sources.list", you mean to look through it and remove anything I don't need anymore?
– Sam Jaques
2 days ago




1




1




@SamJaques yeah eliminate anything you no longer need but more importantly make sure the URLs remain legit.
– slm♦
2 days ago




@SamJaques yeah eliminate anything you no longer need but more importantly make sure the URLs remain legit.
– slm♦
2 days ago












 

draft saved


draft discarded


























 


draft saved


draft discarded














StackExchange.ready(
function ()
StackExchange.openid.initPostLogin('.new-post-login', 'https%3a%2f%2funix.stackexchange.com%2fquestions%2f460525%2fwhy-isnt-it-a-security-risk-to-add-to-sources-list%23new-answer', 'question_page');

);

Post as a guest













































































Popular posts from this blog

How to check contact read email or not when send email to Individual?

Bahrain

Postfix configuration issue with fips on centos 7; mailgun relay