Bug 495636
| Summary: | Pinning doesn't work as intended | ||
|---|---|---|---|
| Product: | [Fedora] Fedora | Reporter: | Eli Wapniarski <eli> |
| Component: | apt | Assignee: | Axel Thimm <axel.thimm> |
| Status: | CLOSED NOTABUG | QA Contact: | Fedora Extras Quality Assurance <extras-qa> |
| Severity: | medium | Docs Contact: | |
| Priority: | low | ||
| Version: | rawhide | CC: | pmatilai |
| Target Milestone: | --- | ||
| Target Release: | --- | ||
| Hardware: | All | ||
| OS: | Linux | ||
| Whiteboard: | |||
| Fixed In Version: | Doc Type: | Bug Fix | |
| Doc Text: | Story Points: | --- | |
| Clone Of: | Environment: | ||
| Last Closed: | 2009-04-15 07:02:25 UTC | Type: | --- |
| Regression: | --- | Mount Type: | --- |
| Documentation: | --- | CRM: | |
| Verified Versions: | Category: | --- | |
| oVirt Team: | --- | RHEL 7.3 requirements from Atomic Host: | |
| Cloudforms Team: | --- | Target Upstream Version: | |
| Embargoed: | |||
|
Description
Eli Wapniarski
2009-04-14 07:35:17 UTC
(In reply to comment #0) > This is a security problem. It is a security problem becasue, if ATrpms can > manage to override explicit pinning than others can. Speaking as an ATrpms representative, I can assure you that ATrpms is not overriding any explicit pinning of yours. You could argue that the pinning mechanism in apt or its documentation is broken, but that doesn't mean that some repo already is using "security holes" in apt to override your setup. > It would then be possible > and indeed likely that a package not intended by a user to be installed or > updated is which could either result in a comprised or a broken system. All other points aside, If you assume that some repo you point to has malicious software controlled by a hacking entry, then why should that be limited to the packages you have been excluding? In reality if there were such a scenario all packages from the compromised source would be suspicious, even the ones you do not filter away. > There is a similar problem with yum. So the bug report for yum will be almost > verbatim with this one. yum's and apt's filtering whether its called pinning, priorities, protectbase etc. are quite different. > I have a problem properly prioritizing [...] Which means (as far as I > understand) I should see packages for which dependencies are met from repos > other than ATrpms. > However this is not the case. In order for someone to verify any faulty behaviour you should please provide specific examples, best as a minimal bug exposing setup, and the output you get from apt. The typical bug template asks you for steps you took, expected results and actual results. Axel. I'm not claiming anyone is doing anything malicious. What I am suggesting is that both yum and apt have a problem. In that however the repos are organized, if I prioritize a repo, my explicit instructions should never be overriden. But that's exactly what happens. A user who is not paying attention (and its a likely scenario) since the user generally trusts the software that is being is used can potentially have something installed that is "undesired" due to this unexpected behavior. And, that constitutes a security risk. The behavior is exihibited both by apt and by yum.
My apt's preferences has no reference to the ATrpms repository which means the default priority of 500 It should never override anything with a pin-priority above it. But that's exaclty what happnes. ATrpms overrides everthing else. The output of apt-get -f dist-upgrade is included below. This type of behavior is always reproducable.
-----------
PREFERENCES
-----------
Package: *
Pin: release c=fedora-10-x86_64-stable
Pin-Priority: 1004
Package: *
Pin: release c=fedora-10-x86_64-testing
Pin-Priority: 1004
Package: *
Pin: release c=fedora-10-x86_64-unstable
Pin-Priority: 1004
Package: *
Pin: release c=fedora-linux-releases-10-Everything-x86_64-os
Pin-Priority: 1004
Package: *
Pin: release c=fedora-linux-updates-10-x86_64
Pin-Priority: 1004
Package: *
Pin: release c=free-fedora-updates-10-x86_64
Pin-Priority: 1002
Package: *
Pin: release c=nonfree-fedora-updates-10-x86_64
Pin-Priority: 1002
package: rpm
Pin: version 4.6.0-10*
Pin-Priority: 1005
package: rpm-libs
Pin: version 4.6.0-10*
Pin-Priority: 1005
package: rpm-build
Pin: version 4.6.0-10*
Pin-Priority: 1005
package: rpm-devel
Pin: version 4.6.0-10*
Pin-Priority: 1005
package: rpm-python
Pin: version 4.6.0-10*
Pin-Priority: 1005
package: wine-capi.32bit
Pin: version 1.1.19-1*
Pin-Priority: 1005
package: wine-cms.32bit
Pin: version 1.1.19-1*
Pin-Priority: 1005
package: wine-core.32bit
Pin: version 1.1.19-1*
Pin-Priority: 1005
package: wine-desktop.32bit
Pin: version 1.1.19-1*
Pin-Priority: 1005
package: wine-devel.32bit
Pin: version 1.1.19-1*
Pin-Priority: 1005
package: wine-esd.32bit
Pin: version 1.1.19-1*
Pin-Priority: 1005
package: wine-jack.32bit
Pin: version 1.1.19-1*
Pin-Priority: 1005
package: wine-ldap.32bit
Pin: version 1.1.19-1*
Pin-Priority: 1005
package: wine-nas.32bit
Pin: version 1.1.19-1*
Pin-Priority: 1005
package: wine-pulseaudio.32bit
Pin: version 1.1.19-1*
Pin-Priority: 1005
package: wine-tools.32bit
Pin: version 1.1.19-1*
Pin-Priority: 1005
package: wine-twain.32bit
Pin: version 1.1.19-1*
Pin-Priority: 1005
package: wine.32bit
Pin: version 1.1.19-1*
Pin-Priority: 1005
---------------------
CONTENTS OF LIST FILE
---------------------
repomd http://dl.atrpms.net/f10-x86_64 atrpms/stable
--------------------
apt-get -f dist-upgrade
--------------------
The following packages will be upgraded
atrpms (71-1 => 73.1-1)
faad2-devel (2.6.1-6.fc10 => 2.7-16.fc10)
lame (3.98.2-2.fc10 => 3.98.2-19.1.fc10)
libdca (0.0.5-3.fc10 => 0.0.5-4.fc10)
libdvdcss (1.2.10-1 => 1.2.10-5.fc10)
libdvdcss-devel (1.2.10-1 => 1.2.10-5.fc10)
libquicktime-devel (1.0.3-4.fc10 => 1.1.1-25.fc10)
mjpegtools (1.9.0-0.6.rc3.fc10 => 1.9.0-18.fc10)
mjpegtools-devel (1.9.0-0.6.rc3.fc10 => 1.9.0-18.fc10)
mplayer-skins (1.8-1 => 1.0-pre3_13.at)
unrar (3.7.8-3.fc10 => 3.8.4-1.fc10)
vcdimager (0.7.23-8.fc10 => 0.7.23-9.fc10)
vcdimager-devel (0.7.23-8.fc10 => 0.7.23-9.fc10)
x264-devel (0.0.0-0.18.20080905.fc10 => 0.65-9_20090117.2245.fc10)
yum-plugin-kmdl (0.8-10.fc9 => 0.8-11.fc10)
zonecheck (2.0.4-3.fc9 => 2.0.4-3.fc10)
The following packages will be REPLACED:
vcdimager-libs (2.0.2-2.lvn9)
(by (0.4.9-0.55.20080908.fc10)
vcdimager) (0.4.9-0.55.20080908.fc10)
The following packages will be REMOVED:
akode-extras (2.0.2-2.lvn9)
ffmpeg (0.4.9-0.55.20080908.fc10)
ffmpeg-devel (0.4.9-0.55.20080908.fc10)
ffmpeg-libs (0.4.9-0.55.20080908.fc10)
ffmpeg2theora (0.21-2.fc10)
gecko-mediaplayer (0.9.5-1.fc10)
gnome-mplayer (0.9.5-1.fc10)
gnome-mplayer-common (0.9.5-1.fc10)
gstreamer-ffmpeg (0.10.5-1.fc10)
gstreamer-plugins-bad (0.10.9-1.fc10)
gstreamer-plugins-bad-devel (0.10.9-1.fc10)
gstreamer-plugins-bad-extras (0.10.9-1.fc10)
k3b-extras-freeworld (1.0.5-4.fc10)
kino (1.3.3-1.fc10)
kino-devel (1.3.3-1.fc10)
lame-mp3x (3.98.2-2.fc10)
libquicktime (1.0.3-4.fc10)
mencoder (1.0-0.104.20090204svn.fc10)
mjpegtools-gui (1.9.0-0.6.rc3.fc10)
mjpegtools-libs (1.9.0-0.6.rc3.fc10)
mozilla-vlc (0.9.8a-1.fc10)
mplayer (1.0-0.104.20090204svn.fc10)
mplayer-gui (1.0-0.104.20090204svn.fc10)
vlc (0.7.23-8.fc10)
vlc-core (0.9.8a-1.fc10)
vlc-devel (0.9.8a-1.fc10)
vlc-nox (0.9.8a-1.fc10)
x264-gui (0.9.8a-1.fc10)
x264-gui-devel (0.0.0-0.18.20080905.fc10)
The following NEW packages will be installed:
libdca0 (0.0.5-4.fc10)
libdvdcss2 (1.2.10-5.fc10)
libfaad0 (2.6.1-13.fc10)
libfaad2 (2.7-16.fc10)
libmp3lame0 (3.98.2-19.1.fc10)
libquicktime0 (1.1.1-25.fc10)
libvcdinfo0 (0.7.23-9.fc10)
libx264_65 (0.65-9_20090117.2245.fc10)
(In reply to comment #2) > What I am suggesting is that both yum and apt have a problem. Please separate apt and yum, their behaviour/coding is very different. Even if the symptoms may look similar, they need to be addressed in different bug reports. > In that however the repos are organized, if I prioritize a repo, my explicit > instructions should never be overriden. Indeed, but looking at the example you just have a misconfiguration. > But that's exactly what happens. A user who is not paying attention > (and its a likely scenario) since the user generally trusts the software that > is being is used can potentially have something installed that is "undesired" > due to this unexpected behavior. And, that constitutes a security risk. The > behavior is exihibited both by apt and by yum. In this case it looks like user error and this may of course always be a security risk. :) For yum please open a different bug. > My apt's preferences has no reference to the ATrpms repository which means the > default priority of 500 It should never override anything with a pin-priority > above it. But that's exaclty what happnes. ATrpms overrides everthing else. Actually you have never set any preferences for anything else, since wildcards don't work. > Package: * > Pin: release c=fedora-linux-updates-10-x86_64 > Pin-Priority: 1004 Half a year ago you submitted a feature request (bug #462831), which is still in ASSIGNED state to allow for globing in apt's preferences. So actually you should know beforehand that the config is not valid. Please confirm and decide for yourself whether this is NOTABUG or a DUPLICATE of bug #462831. (In reply to comment #3) > (In reply to comment #2) > > What I am suggesting is that both yum and apt have a problem. > > Please separate apt and yum, their behaviour/coding is very different. Even if As indicated, its already been done. > > > In that however the repos are organized, if I prioritize a repo, my explicit > > instructions should never be overriden. > > Indeed, but looking at the example you just have a misconfiguration. No sir there is no misconfiguration. ATrpms have not been prioritized at all which means it is equivalent to a preference setting that would read like this Package: * Pin: release c=atrpms-stable Pin-Priority: 500 Quoting from man apt_preferences "If the target release has not been specified then APT simply assigns priority 100 to all installed package versions and priority 500 to all uninstalled package versions... Note that none of APT's default priorities exceeds 1000" Which means that none of ATrpms should try to replace or uninstall anything in that I've prioritized above 1000. > > But that's exactly what happens. A user who is not paying attention > > (and its a likely scenario) since the user generally trusts the software that > > is being is used can potentially have something installed that is "undesired" > > due to this unexpected behavior. And, that constitutes a security risk. The > > behavior is exihibited both by apt and by yum. > > In this case it looks like user error and this may of course always be a > security risk. :) Not noticing is indeed a "user error" but similarly places an unfair burden of responsibility due to unexpected behavior. > > For yum please open a different bug. > > > My apt's preferences has no reference to the ATrpms repository which means the > > default priority of 500 It should never override anything with a pin-priority > > above it. But that's exaclty what happnes. ATrpms overrides everthing else. > > Actually you have never set any preferences for anything else, since wildcards > don't work. > > > Package: * > > Pin: release c=fedora-linux-updates-10-x86_64 > > Pin-Priority: 1004 Axel please believe me... This works and it works very very well. package: kde* Pin: release c=fedora-linux-updates-testing-9-x86_64.newkey Pin-Priority: 1005 This on the other hand does not. Be that as it may. Having ATrpms trying to replace packages prioritized higher than ATrpms is a no no and a different bug. All together than the feature request to use wildcards for a family of packages. > Half a year ago you submitted a feature request (bug #462831), which is still > in ASSIGNED state to allow for globing in apt's preferences. So actually you > should know beforehand that the config is not valid. > > Please confirm and decide for yourself whether this is NOTABUG or a DUPLICATE > of bug #462831. This is neither NOTABUG nor is it a DUPLICATE but 2 completely different issues. Please, could we stop debating. And bring Panu into the picture. Let him decide whether or not this is a bug. This not a packaging issue but a programming issue. Actually.. Please wait on this. Maybe a very very very big oops on my part. Crap crap crap crap... and crap again.... My most sincere and humble apologies. I feel like a complete moron this time.. Completely my oversite. Please close with my thanks (In reply to comment #4) > Please, could we stop debating. And bring Panu into the picture. Let him decide > whether or not this is a bug. This not a packaging issue but a programming > issue. Panu had been in the loop since I added him a couple of comments ago. (In reply to comment #6) > Crap crap crap crap... and crap again.... My most sincere and humble apologies. > I feel like a complete moron this time.. > > Completely my oversite. Can you please elaborate for the archive's sake? What was the real problem? > Please close with my thanks I'm not sure who can close it - once you call it a security bug it can't be untagged as such, at least not by me. Try closing it NOTABUG. First off. Please accept my most humble apologies. I really do feel embarrassed as an ass and an idiot over this. If I remember correctly. And this was quite some time ago. I had some issues regarding conflicts between rpmfusion - everything (free or nonfree I can't remember). I can't remember the exact circumstances. So the gist of things is that both "everything" repos were disabled under apt. Of course this was supposed to be a temporary situation ;). I re-enabled the repos and added them to my preferences file along with livna because there is still one package that will not be maintained at rpmfusion but either in livna or freshrpms. And thats the whole story. As an aside, in case your curious, the problem that I had with yum was obscurity over a feature in the priorities plugin. It turns out that I needed to add the line: check_obsoletes=1 to priorities.conf to deal with this. arrrgh. Again. Thank you very much. And let this be a lesson to me. Tired and computers don't work very well together. :). |