4 ms·

I use the ppa, but doing that opens you up to security concerns. I've tried to build from source, but there are too many dependencies and I couldn't build it d

I use the ppa, but doing that opens you up to security concerns. I've tried to build from source, but there are too many dependencies and I couldn't build it due to conflicting libraries.

ViViDboarder 8y ago
If you trust the PPA you added, does it open you up to any other concerns?
- r3bl 8y ago
  In an ideal case, no. In a not-so-ideal case, one with the push access could theoretically replace any package on your system with a malicious version that you would pick up automatically using apt upgrade. I'd trust PPAs more if they didn't have such broad possibility of misuse. For example, if I add a PPA that only contains package A, I should at least be warned if that PPA tries to install or upgrade package B. apt will only display that package B needs to be installed/upgraded, it won't inform me that it originated from that PPA. I applaud elementary OS for not bundling software-properties-common by default (a package that allows you to run add-apt-repository). If you decide to install it, you should at least be forced to make an effort to open such possibility of misuse.
  - dalai 8y ago
    I think you can use pinning to prevent the second scenario, assuming you don't mind the extra manual configuration.
michaelmrose 8y ago
Security is a spectrum not an on off switch. The question is whats the risk profile/benefit. The ppa like many other is hosted on launchpad.net owned by canonical. If Canonical is compromised you are probably boned any way you slice it. If the developer is compromised you are probably boned. This leaves the fact that the devs account on launchpad could be taken over and used as an attack vector which quite frankly seems like the lessor risk. You have already undertaken the greater risk that the dev or whomever inherits/acquires access to their account is or becomes malicious or incompetent especially given that is not now or will it be audited unless it becomes an official part of the Ubuntu repos. This means that if the bookworm software in version 17 starts to come with a crypto miner you will only become aware of this if it hits hacker news and you happen to read the story whereas were it part of the Ubuntu repos Canonical would be apt to publish this warning via official channels. If you have 835 packages you have 835 potential sources of issues but if they are all vetted by canonical then you have 1 source of fixes/warnings. If you add 17 ppas you now have 18 channels and 17 may be less diligent than canonical is. This situation isn't much improved if you have 17 github repos that you periodically pull from unless you have both the skill and the time to audit the result in depth.
- debiandev 8y ago
  On PPA you need to trust a random individual instead of trusting an official distribution. Some distribution requires multiple pair of (skilled) eyes to vet a package.
  - michaelmrose 8y ago
    The point is you do the same when you build the source. In many cases the ppa is provided by the same person providing the source.

I use the ppa, but doing that opens you up to security concerns. I've tried to build from source, but there are too many dependencies and I couldn't build it due to conflicting libraries.

ViViDboarder 8y ago

If you trust the PPA you added, does it open you up to any other concerns?

r3bl 8y ago
In an ideal case, no. In a not-so-ideal case, one with the push access could theoretically replace any package on your system with a malicious version that you would pick up automatically using apt upgrade. I'd trust PPAs more if they didn't have such broad possibility of misuse. For example, if I add a PPA that only contains package A, I should at least be warned if that PPA tries to install or upgrade package B. apt will only display that package B needs to be installed/upgraded, it won't inform me that it originated from that PPA. I applaud elementary OS for not bundling software-properties-common by default (a package that allows you to run add-apt-repository). If you decide to install it, you should at least be forced to make an effort to open such possibility of misuse.
- dalai 8y ago
  I think you can use pinning to prevent the second scenario, assuming you don't mind the extra manual configuration.

michaelmrose 8y ago

Security is a spectrum not an on off switch. The question is whats the risk profile/benefit. The ppa like many other is hosted on launchpad.net owned by canonical. If Canonical is compromised you are probably boned any way you slice it. If the developer is compromised you are probably boned. This leaves the fact that the devs account on launchpad could be taken over and used as an attack vector which quite frankly seems like the lessor risk. You have already undertaken the greater risk that the dev or whomever inherits/acquires access to their account is or becomes malicious or incompetent especially given that is not now or will it be audited unless it becomes an official part of the Ubuntu repos. This means that if the bookworm software in version 17 starts to come with a crypto miner you will only become aware of this if it hits hacker news and you happen to read the story whereas were it part of the Ubuntu repos Canonical would be apt to publish this warning via official channels. If you have 835 packages you have 835 potential sources of issues but if they are all vetted by canonical then you have 1 source of fixes/warnings. If you add 17 ppas you now have 18 channels and 17 may be less diligent than canonical is. This situation isn't much improved if you have 17 github repos that you periodically pull from unless you have both the skill and the time to audit the result in depth.

debiandev 8y ago
On PPA you need to trust a random individual instead of trusting an official distribution. Some distribution requires multiple pair of (skilled) eyes to vet a package.
- michaelmrose 8y ago
  The point is you do the same when you build the source. In many cases the ppa is provided by the same person providing the source.