Hey Axel On Wed, 2014-11-05 at 05:06 +0100, Axel Beckert wrote: > AFAIK they actually _are_ the ultimate group to decided where the > security tag applies to. Well even though I see them behaving like that, I didn't found any place where it's written... and actually some other people complained about that as well... so I rather take "security" as "security" and not "security-team" tag.
> It indeed seems as if you missed some facts: > https://alioth.debian.org/project/memberlist.php?group_id=30020 > > You may also want to have a look at who signed the latest and some > earlier uploads of aptitude: https://tracker.debian.org/pkg/aptitude Ah,.. well I didn't see that,... just looked up the list at packages.debian.org. > And as long as I'm the only aptitude team member who has an opinion > about this bug report, you should consider my opinion as being the > maintainer's opinion -- and respect it accordingly. Well nevertheless,... I still think it's rather impolite to change such things without any further discussion. Anyway... I guess discussing about this is a waste of time. > > Just because e.g. lcms1 is no longer upgraded in unstable, this > > should mean that aptitude proposes it to downgrade to a "new" older > > version, when a security update comes out. > > I disagree. Such a behaviour would be wrong and should be considered a > bug if it appears with the default pinning. Argl... that happens when one answers to bugs so late in the night. Of course I meant "this should *not* mean". That was the whole point what I've tried to lay out: aptitude should of course NOT override what I've set explicitly in the apt_preferences mechanism and simply downgrade when it sees "oh there is a security update which won't get into the users's target suite". But this is just the problem what we end up with: There is a package, which no longer receives updates, and of course, it won't and shouldn't (at least not automatically) receive the updates via the "deselected" stable suite... but it definitely should somehow tell the user what's going on (i.e. obsoleting the package/version combination). As otherwise, the user won't notice for a very very long time, that he runs a package which is potentially not security supported anymore. If this wouldn't be a corner case (i.e. the mixture of different suites/repos) I'd even set the security to something higher than critical),... but so I still think "important" is appropriate. Because as I've explained, this may also affect mixtures of different repos but same suite. > The list of upgradable packages is controlled by pinning in similar > ways. And I don't think that aptitude should override pinning (be it > default or local) in any way unless the local admin overrides it > interactively or on the commandline. (Which IMHO is easier to do with > aptitude than with apt.) Sure... sorry for the confusion, by forgetting the "not" > The security tag is debatable. The said feature may involve security > updates under the circumstances you described. I know that this kind > of setup is not that uncommon(*), but it's still very specific and > especially _unsupported_. Is it? I mean I could imagine that mixing Debian's stable with unstable is _officially_ unsupported (even though it works quite fine in practise, and I guess it's not so rarely used)... but mixing Debian's stable with xyz's stable should be supported... not from the point that packages work with each other, but that you don't run into a situation as described here. > I still think we should not tag bug reports > as security if they only involve unsupported setups (unstable with > security updates from stable) and especially if they involve > officially unsupported features (downgrading). Well... I personally say, rather tag one too much than not. And I mean "security" seems to not imply "security in an officially supported setup"... I'd rather understand it via common sense as a general tag "something that may somehow affect security". And I guess no one is pointing publicly with the finger to you aptitude maintainers, just because you have such a bug open?! Anyway we're talking about useless formalities here... rather than the issue itself. > I though agree that having a group showing "newer than in archive" > packages would be a helpful _feature_ in general. mhh... "newer than in archive"... I probably need to think whether this is what we actually want here... In general it sounds interesting, but I don't think it solves the specific problem here, because the security issue described here, could also just happen the other way round (at least in theory), i.e. someone pins a package to stable, it's dropped from there or support because support is ended (something like iceweasel)... but it continues to remain in unstable, so the user would again not notice that he doesn't receive anymore updates. Now I don't think this ever happened so far, and one could argue like Russ did in the other thread I've mentioned, that it's in the responsibility of the user to read DSAs and get notified about problems (at lets forget for the moment that there is in principle no secure way of distributing DSAs). And still, I think we should have a proper solution for this which by definition handles all possible corner cases (even such we don't see right now). Have you looked at my proposal of how "obsolete" should be defined in message #26? And what do you think about it? For me, that would be the natural meaning of "obsolete package" as I'd understand it based on common sense (and not on having to look up some definition). And I guess it also takes into account the multi repo/suite scenarios quite well. For must users nothing would probably chance, and for those using pinning,... they would actually see whether package+version combinations are obsolete and not just packages > also because you already can > search for according packages or limit the view to them as explained > in my previous mail. Well my point here is: Of course you can. You can also just disable the stable repo (in my example) for a moment, start aptitude and have a look what became "obsolete". But this, as well as your nice search string, is nothing that the average user will ever do (because he even doesn't think about this issue),... neither would automated tools like Nagios/Icinga's check_apt do. Best wishes, Chris.
smime.p7s
Description: S/MIME cryptographic signature
_______________________________________________ Aptitude-devel mailing list [email protected] http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/aptitude-devel
